The Great Content Migration

[Karsten Wade]

On Sun, 2007-12-02 at 12:16 -0500, Paul W. Frields wrote:
> > On Fri, 2007-11-30 at 16:35 -0600, Mike McGrath wrote:

> I am completely talking out of my sitting apparatus here, but isn't it
> possible for Jon's docs workflow to be applied to only some of the
> content of a Plone instance -- i.e. the stuff in a Docs-type namespace?
> In other words, everything else, like marketing pages, front page, etc.
> could be put through "normal" ("default"?) workflow.  I have no idea if
> this is so; hopefully Jon can say for sure.

I think you are right and I forgot this.  Our custom workflow can be
applied to just a section of the Plone install, and leave the standard
workflow for the rest of the content.

> Biggest risk of the community contribution model -- it's easy to "fire
> and forget"... with the emphasis on the last half.  I think everyone
> agrees the benefits outweigh the risk, but it does create maintenance
> needs.

... and ...

> > But who's the target audience for the wiki?  In the past its sort of 
> > been targeted for everyone but the content was mostly just for developers.
> 
> We have to strike a delicate balance in Fedora, because our distribution
> is fast-moving.  New ideas are coming up all the time and it's too much
> work to ask contributors to do more than write up a quick wiki page.
> Having a function to alert users to stale pages of theirs -- pages that
> haven't been updated or visited in X months -- might help.  Pages that
> seldom change might be better suited as official documentation, but it
> would depend on how tight the focus of the page is, to avoid jacking up
> the maintenance cost for trivia pages.

A big wiki really needs a team tasked to touching pages.  One job is to
decide if a page needs a maintainer (owner) and get that person to
commit to it (put their name at the bottom as owner).  Another is to fix
inconsistencies in markup, format, etc.  An important one is to create
and maintain clickstreams that are useful on the front page and other
sub-pages that are starting points (i.e., ProjectName/ namespaces.)

> That reminds me to point out that the user "personal" page content on
> the wiki is worthwhile to keep where it is.  We can't assume every
> contributor is going to write his or her own HTML for fedorapeople.org
> if we want folks like artists, documentation writers, marketing people,
> and so forth to be attracted to work on the project.  Those who are
> comfortable doing so can certainly choose their location and link as
> desired.

Good point.  The wiki isn't a bad place for this content.

> Not really, I guess.  We should also note that there are Plone modules
> available for wiki functionality if they're really needed, although
> honestly the Plone document writing tools are as easy and inviting as
> the wiki tools, only better.  I have no idea what the ETA of the new
> workflow stuff is.

The part you aren't considering is that the Docs workflow is access
controlled.  Just anyone cannot drop in and work on it without going
through the join-the-project steps.  The wiki is different, culturally
and programmatically. 

I'd suspect that most on-team writers would stop using the wiki, but we
still need to be open for contributions from the entirety of the Fedora
Project in places such as Docs/Beats/.

The fact is, there are going to be some docs that will never leave the
wiki because the subject matter expert doesn't want to work on it in
another location.  *Maybe* we can get them to work it as a normal
workflow Plone document, but not likely to get that xhtml => xml-in-SCM
that our custom workflow is for.

- Karsten
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20071202/8a3e11b6/attachment.sig>