openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Structure of the CWiki?
Date Thu, 18 Jul 2013 18:40:50 GMT
On Thu, Jul 18, 2013 at 2:12 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Jul 18, 2013, at 9:43 AM, janI wrote:
>
>> On 18 July 2013 16:50, Rob Weir <robweir@apache.org> wrote:
>>
>>> On Thu, Jul 18, 2013 at 10:33 AM, janI <jani@apache.org> wrote:
>>>> On 18 July 2013 15:29, Rob Weir <robweir@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.  But the rewards
seem less tangible than the effort required to get there.

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-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message