Comments inline below.
Simon
Simon Laws wrote:
Conversation seems to have stopped so, from the previous comments...
* Confluence admins:
Venkat, Luciano, Mike Edwards [1] have been proposed to cover the timezones
we operate in. Venkat are you progressing this?
* http://cwiki.apache.org/confluence/display/TUSCANY space access:
As this is now feeding our main (http://incubator.apache.org/tuscany/)
website we have been advised to restrict access to committers to prevent
our
shop front acquiring dubious content. I have removed "create" access from
confluence users as I think we have been sailing close to the wind on this
and it would be a shame to have our web site messed up, particularly as
we've recently put out releases and we hope people are looking at them.
There are alternative approaches to this blanket change, for example, we
may
be able to mark all of the web site pages in the /TUSCANY spaces as
restricted but this would take some effort and complicate the management
task We could also stop the automatic generation of the site and do it on
demand manually but the idea of linking up the wiki to generate the web
site
was to avoid this.
The main option that is on the table is to go with the committer only
access
to the TUSCANY space and create other spaces for whatever else we need, for
example, a generally accessible wiki. Luciano has started a conversation
about this [2] but I don't see much feedback. If you feel strongly can you
go and comment so that we can move this forward quickly now we are
restricting create access to /TUSCANY
I feel strongly that we do need a generally accessible wiki, and that
part of this wiki needs to be a copy of the Web site wiki so that
non-committers can make and preview proposed changes to the Web site.
See below for more detail on this.
* Contributions to the web site
We need to describe a mechanism where non-committers can contribute content
to the web site. Looking at the comments here it seems that this will have
to be through attaching text, cwiki markup or whatever other resources are
required (png, jpg etc) to JIRA so that a committer can update the site.
Logically this is no different from the situation we had when the site was
maintained out of svn except of course that we could use diffs then.
This proposed new process has one significant difference from how things
used to be. When the Web site was based on svn, a non-committer could
check out the site, make proposed changes, generate the site to preview
these changes (very important when editing a Web site), and when satisified,
generate an svn diff to attach to a JIRA. The main overhead was having to
regenerate the site after every source change to preview the change, but
this was tolerable if not ideal.
With the current Wiki-based approach, it appears we have lost the ability
for non-committers to make changes and preview them. I have spent some
time exploring how the site is put together and I have been able to find
all the source. So I could edit the source to make proposed changes, and
I could run a regular non-svn diff command to generate diffs, but AFAIK
there's no easy way for me to preview the appearance of my proposed
changes. This is a huge problem for updates to a Web site, where the
visual appearance is a very important component of whether a change is
good or not.
Setting up a clone of the real site in a space that's accessible to
non-committers would allow changes to be previewed in this space.
Unfortunately this comes with the overhead of keeping the closed space
and the open space very closely in sync, or else the open space will
quickly become obsolete and worthless for its intended purpose.
A procedure to ensure this synchronization could be:
1. Initially the two spaces are the same.
2. A committer makes changes to the closed space. He or she must
immediately also reflect those changes into the open space.
3. A non-committer makes changes to the open space, previews them
in the open space, and generates a JIRA update for the changes.
4. A committer takes the changes from the JIRA (also in the open
space), and reviews them to see if they are acceptable.
a. If they are acceptable "as is", the committer updates the
closed space with the changes.
b. If they are partially acceptable, the committer makes any
modifications necessary and updates both the closed and
open spaces accordingly.
c. If they are not acceptable, the committer backs them out of
the open space.
It is possible that steps 2 and 4c could be replaced by an automated
process that regularly compares the closed space to the open space
and updates the open space with any changes to the closed space.
This could wipe out changes to the open space made in step 3 by a
non-committer, but this is recoverable since they are captured in a
JIRA, and the wiki keeps a record of all previous versions of pages.
The process descibed above involves some overhead for both committers
and non-committers, but this seems to be a necessary cost of continuing
to allow non-committers to make and preview changes to the Web site in
the same way as they are able to make and preview changes to code
(by building and testing those changes).
Any other suggestions for how to resolve this issue are very welcome.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
