On Thu, Jul 18, 2013 at 11:40 AM, Rob Weir <robw...@apache.org> wrote:
> On Thu, Jul 18, 2013 at 2:12 PM, Dave Fisher <dave2w...@comcast.net>
> wrote:
> >
> > On Jul 18, 2013, at 9:43 AM, janI wrote:
> >
> >> On 18 July 2013 16:50, Rob Weir <robw...@apache.org> wrote:
> >>
> >>> On Thu, Jul 18, 2013 at 10:33 AM, janI <j...@apache.org> wrote:
> >>>> On 18 July 2013 15:29, Rob Weir <robw...@apache.org> wrote:
> >>>>
> >>>>> We have the opportunity to restructure the pages on our CWiki.
> When
> >>>>> looking over the current structure it looks like we've been taking
> two
> >>>>> entirely different approaches to organizing the information:
> >>>>>
> >>>>> 1) A team-oriented approach, where at the top organizational level
> >>>>> there are parent pages for each team, dev, qa, doc, l10n., etc.
> >>>>>
> >>>>> 2) A release-oriented approach, where the top level is a specific
> >>>>> release, like AOO 3.4.1 or 4.0, and subpages are used for status and
> >>>>> plans for functional groups.
> >>>>>
> >>>>> These two approaches look like they are both being used, but not
> >>>>> consistently.
> >>>>>
> >>>>> I wonder if would be worth being more consistent, and doing something
> >>> like:
> >>>>>
> >>>>> 1) Have a top-level page for each functional group, for tracking
> >>>>> release-independent information, e.g., links to useful other pages,
> >>>>> lists of volunteers, "how to" information. The stuff that does not
> >>>>> change from release to release. It is information about the team and
> >>>>> what they do, not information about tasks for a specific release.
> >>>>>
> >>>>> 2) Then have top-level release-specific pages, where we store plans
> >>>>> and status reports, dashboards, etc., associated with a release.
> >>>>>
> >>>>> I think this is not so far from what the CWiki was evolving toward.
> >>>>>
> >>>>
> >>>> If we anyhow think about restructuring, why not also think of a merge
> >>> with
> >>>> mwiki...it does not seem correct that we need all these flavours of
> wiki,
> >>>> and it do cost maintenance.
> >>>>
> >>>
> >>> Restructuring is just drag and drop in CWiki. Migration would be more
> >>> effort, but we could restructure while migrating. But a non-trivial
> >>> effort unless there is a tool that automates page conversion, moving
> >>> images, etc.
> >
> > Exactly.
> >
> >>>
> >>
> >> So because its complicated we keep maintaining at 2 different
> >> products....We should have been a goverment agency.
> >
> > Don't cast this kind of note about why we have two wikis. We got the
> CWiki on day one of the project at Apache. The Mwiki remained at Oracle for
> many months. (1) It took some time to get a volunteer named Terry E to do
> the migration which you have taken over. Thank you. (2) Ask on #asfinfra if
> you want to find out about the "difficulties" that occurred.
> >
> > The CWiki serves its purpose very well.
> >
> >> But I get your point, and wont press further for a simpler maintenance.
> >
> > If the project wants to move to one wiki - sure go ahead. I'll help
> however I can when I have time. I would perfectly happy to longer have to
> Admin it which quite frankly has not been much of an effort. How much
> effort has it taken to manage MWiki?
> >
> > The balance is that the ASF manages Confluence, but the project must
> manage our own MediaWiki.
> >
> > Since the ASF is considering WordPress as a replacement for Roller.
> Maybe some of the CWiki content belongs there?
> >
>
> Certainly the blog could move to WordPress. I know WordPress pretty
> well, been using it for 8 years or so on my personal blog. It has
> support for blog posts as well as "pages", which can be static content
> that is not tied to a post or a typical RSS stream. But I'd probably
> just use that for content that is very strongly associated with the
> blog, e.g., a comment policy or a page that tells where to go for
> support. It might not be worth using it for yet-another-cms for the
> project.
>
> Most of the stuff we have on CWiki is inward-facing pages that we use
> to coordinate on parts of the project. I think that is distinct from
> the blog content. And maybe even distinct from what most of the MWiki
> is used for, which is more user facing.
>
> As you know, we've had this discussion before and more than once. We
> have the same situation with www.openoffice.org versus
> openoffice.apache.org. Project-facing versus user-facing.
>
> Of course, this doesn't determine our technical approach. We could
> use a single technology and have both project-facing and user-facing
> content in the same tool, if we structured it right.
...yes...
> But the rewards
> seem less tangible than the effort required to get there.
>
I'm not sure about this one. Migration, of some sort, is a one time deal.
Administration is forever.
>
> Regards,
>
> -Rob
>
> > Anyone object to the deletion of the unused OOODEV cwiki?
> >
> > Regards,
> > Dave
> >
> >>
> >> rgds
> >> jan I.
> >>
> >>
> >>>
> >>> -Rob
> >>>
> >>>> rgds
> >>>> jan I.
> >>>>
> >>>>
> >>>>>
> >>>>> -Rob
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
Success is falling nine times and getting up ten."
-- Jon Bon Jovi
