Mailing List Archive

Hi,

please excuse my intrusion into this thread. I must admit I did not
find the time to install PTK anywhere yet. Nevertheless I would like
to throw in my thoughts and more importantly wishes for this great
new thing, as I might have needs not mentioned yet.

Kevins ideas are really great - I guess he has seen many things on
portals because of his KM|net news, which I like very much, too.

As to the reviewing I would like to add my thoughts, because I have
not found any mentioning of this:

It is quite possible that people are considered Reviewer on one
Topic, but only contributor on another. Let's think of a news site
with several very different topics, no one can be expert in all the
fields, you will probably designate several people or groups for
different areas.

I think this is very important setting for the proposed role of of a
direct contributor, whose articles need not be reviewed. I don't
think many people would like that role to work on all areas of a site.

I don't know if this is already covered by PTK at the moment, but it
is not mentioned in the docs nor was there talk about it on the list
that I am aware of...

Jochen

At 11:23 Uhr -0500 22.01.2000, Kevin Dangoor wrote:
> Thus far, all of the talk about reviewing of new content has centered
>around people having documents that they are individually responsible for
>and that live within their member folders. I could also see cases where
>there are groups responsible for maintaining certain objects. Let's call it
>the "IMDB model".
>
> It may be possible to do this through Versions. But, then you'd probably
>run into difficulty if two people change two different properties of a movie
>before the change for the first one is reviewed.
>
> There could be an object that basically contains information about the
>change. It could just be a dictionary of "property" and "new value"
>pairings. I think Versions would work great, if the whole object wasn't
>locked when a property changes...

Versions would be really great, it even implies that the problems
with versions changing cataloged object need to be resolved :-)
I guess one could live with the drawback that every change needs to
be reviewed before another could be made...

On the other hand, do you know the approach MS gives to the problem
of several reviewers in Word? For every editor the changes get
colored differently, deletes are marked striked-through.
I guess this could be transferred to Zope and would be helpful for
the reviewer anyway (see the old version and what was changed).

You could display the text in the described form on one side, the
editable code in the last state on the right for editing or
additional changes and a reviewer could be presented one change after
another for approval or rejection.

> Anyhow, this is not something that needs to be in ZPT 1.0. But, it is
>something that I think has many applications beyond movies...

Well, as many good changes and additions should make it into ZPT as
soon as possible :-) but I guess this will take some time to work on
:-( But I think the need for reviewing groups and ways to handle the
groups and the work to be done (locking an article when one is
already reviewing it) for them is very important for the PTK as they
defenitely make it aim at bigger projects/clients.


Jochen

These are interesting thoughts. I was considering something much like
this. It would be nice if users could make changes to objects which
didn't appear publicly until they had been approved by a reviewer. This
should include changes that affect the URL, as well as content
changes. The obvious way was to have changes of a published object happen
in a Version. As long as the PortalCatalog can be made smart enough not
to change under Versions this should be doable.

This is something I'm considering for 1.0, but not really for the
first release this week. I want to keep this option open. Can anyone see
any potential trouble while having a few dozen Versions open? The UI
issues are pretty straightforward, I'm more concerned about objects
(and the catalog) locking themselves inconveniently. The catalog should
obviously refuse to update itself if it's in a Version. If anyone knows
any other potential problems, please speak up.

This thread also touched on collaboration. The nature of the web
makes this difficult (perhaps impossible) to get right. I don't see that
this is a design consideration we can realistically entertain. The best
I feel we could manage would be to prevent concurrent editing.

Lastly, Jochen brought up concerns that Reviewer powers are too
all-encompasing. It is possible to designate a person a Reviewer over the
entire site, or any sub-set of the site that you desire, right down to an
individual object, or a collection of individually selected objects. The
standard Zope security model applies to Reviewers. Look up 'local roles'
for more information.

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434

----- Original Message -----
From: "Mike Pelletier" <mike@digicool.com>
To: <zope-ptk@zope.org>
Sent: Sunday, January 30, 2000 9:54 AM
Subject: Re: [Zope-PTK] Another use case for reviewing

> As long as the PortalCatalog can be made smart enough not
> to change under Versions this should be doable.

If you're not using CatalogAware, it seems like you should be able to
control when objects will reindex themselves. Whatever interface you have
that allows a reviewer to check in the changes could check in the version
and reindex all of the objects that were changed. (Just as long as someone
doesn't just check in the version from the management screens...)

> This is something I'm considering for 1.0, but not really for the
> first release this week. I want to keep this option open. Can anyone see
> any potential trouble while having a few dozen Versions open? The UI
> issues are pretty straightforward, I'm more concerned about objects
> (and the catalog) locking themselves inconveniently. The catalog should
> obviously refuse to update itself if it's in a Version. If anyone knows
> any other potential problems, please speak up.

In my IMDB sort of scenario, having a whole object locked for a change (and
not just a property) could be inconvenient. Let's say that one user wanted
to list an additional writer on a movie, while someone else was updating the
plot summary. If the whole movie object was locked, then two people couldn't
submit changes simultaneously.

However, a solution to this problem could be created at an application-level
anyhow. Just make the change form for the object create it's own kind of
version object with the properties and the proposed changes, and then make a
form for the reviewer to accept/reject the changes. So, the Version method
is probably fine for most uses anyhow...

> This thread also touched on collaboration. The nature of the web
> makes this difficult (perhaps impossible) to get right. I don't see that
> this is a design consideration we can realistically entertain. The best
> I feel we could manage would be to prevent concurrent editing.

I think it's fine to not really deal with that aspect in PTK 1.0. I'm
guessing that we'll see some interesting solutions come up from the
community.

Kevin