In this situation where only commiters have access to update the site wiki
the committers have to adopt the role of an editor. New content can come
either as unformatted page content or formatted (for confluence) page
content

Unformatted content, e.g. word docs, text, diagrams etc can be directly
attached to a JIRA. The job for the committer in formatting the new content
is not too difficult as confluence is easy to work with. The hard part was
generating the content in the first place. This is like submitting an
article to a publication.

Providing a mechanism whereby formatted page content can be submitted, e.g.
when you want to change an existing page,  relies on us providing a place
where people can generate and review wiki content, i.e. a new space. Please
comment on Luciano's suggestion here [1] if you think this is the right way
to go, or indeed if you don't, and we can move this forward.

Maintaining exact clones/copies of the site will be problematic however we
go about it (manual or automatic). I propose a slightly different approach.
If we maintain copies of the site menus in the new space then confluence
markup can be copied from the live site (manually) and dropped into a page
in the new space for review and modification as and when required. The
resulting markup can then be attached to a JIRA for proposed addition to the
site.  If would be worth noting the version of the page in the site wiki
that is copied for inclusion on the JIRA. The onus is then on the committer
to reconcile the site page with the requested modification using whatever
tools are most useful (diff, vi, confluence etc) in a similar way that we
would with source code.

With this approach reviewing cross page links will be problematic and also
references to resources held on the site wiki such as diagrams. Unless the
person making the change wants to copy them also of course.

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18622.html

Reply via email to