On Sat, 2007-12-01 at 22:39 -0600, Mike McGrath wrote:
Karsten Wade wrote:
> On Fri, 2007-11-30 at 16:35 -0600, Mike McGrath wrote:
>> Now that F8 shipped and F9 is on the horizon, its time to look at moving
>> some more of that content out of the wiki and either into
. This won't be a fun task.
>> 1) We'll have more control and process around the content that goes to
>> these sites. This allows us to make it more 'official'.
>> 2) It will be more easily translatable.
>> 3) Less reliance on Moin
>> 1) It raises the barrier to create these pages
>> 2) It adds more process
>> 3) Its difficult to determine what content belongs where.
> It doesn't have to raise the barriers or add more process or be
> difficult, if we had a CMS.
> I'd like to see us running *two* instances of Plone. The hacked up
> craziness for docs.fp.o that Jon is doing, and a straight-and-plain-Jane
> version for fp.o.
> Can we do that?
I think it will be very unlikely to have multiple instances of Plone
(one for docs and one for the web team)
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
this is so; hopefully Jon can say for sure.
>> I've created an initial
page for stuff thats
>> in the wiki that is a good candidate for the static content.
>> The trick
>> here is that, and lets be honest, much of what is on the wiki right now
>> is garbage.
> In what sense?
Content duplication, multiple redirects, poor software on the backend
for what we're doing, no integration with FAS, out-dated inaccurate
information. I guess when I look at the docs site I see good accurate
information and when I go to the wiki (and when people come to me with
links from the wiki) I often feel like some (not all) of the content
just is old or otherwise inaccurate. Either way, very little of it is
for users and I can see a non-developer getting lost easily.
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
For example, the tours. What's the clickstream supposed to be to
Linked at the top of the release notes and the release announcement,
There's a lot of good content there, but its not linked to from
on our site except beats AFAIK: http://tinyurl.com/2glg9l
I'd discussed with Max and Jesse on the phone once is getting reps from
all the main groups together for a few meetings before we release. This
bit us this time around for a couple of things like sometimes calling it
the "Gnome Desktop Spin" when in fact its just the "desktop spin".
/me makes note to talk to John about that.
Great idea, +1.
> I see a huge mix of items that are there because that has been
> place for putting non-source code content. Meeting minutes, short
> how-tos, scratch notes, task lists, tables, process forms and templates,
> etc. We could imagine replacing each of those items with a separate
> technology. But they aren't really garbage, in the sense of being
> worthless. They just belong somewhere else, ultimately.
That's a good point, I had thought fedorapeople would take some of this
load off (and it has) but it does feel ill suited to many tasks (like
I'm not really concerned about size so much as target content.
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
>> What do you guys think?
> This is what I think we want to do:
> 1. Call the wiki "community documentation"; define that to mean:
> - Very fluid
> - Quality and consistency of writing not guaranteed
> - Community needs to vet and police
> - Good, simple procedures in place
> - Every page needs an owner or the 'wiki police' are going to
> vaporize it
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.
> 2. Move any content that does not fit that description into
> - Still give projects/contributors appropriate access and control
> - Content can have lifecycle (EOL, archiving, etc.)
> - Information architecture is easier
> In addition, consider ...
> a. Running MediaWiki as the "community docs" wiki engine
We've looked into migrating to MediaWiki (I've considered migrating as
well as just making Moin RO at some point and having people migrate the
content manually. Power in numbers :) So far though both have
initially seemed like a lot of work and I don't think any serious
consideration / plan has been put together.
> b. Having Moin be the "docs wiki" that is used by the Fedora Docs
> writers and contributors for drafting content that is going to land in
Once Jon's Plone instance is up will you guys need a wiki anymore at all
(for your actual docs workflow and stuff?)
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.
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://pfrields.fedorapeople.org/
: stickster @ #fedora-docs, #fedora-devel, #fredlug