openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Structure of the CWiki?
Date Thu, 18 Jul 2013 20:35:27 GMT
Am 07/18/2013 08:41 PM, schrieb janI:
> On 18 July 2013 20:12, 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.
>>
>
> I know when AOO got CWIKI and also part of the remaining story. I have also
> seen quite a lot of Terry E work (He has done quite a lot and I am sorry it
> did not work out between him and infra).
>
> on #asfinfra (where I am online)  root@ already told me some time ago about
> the initial setup and terry E. These difficulties was more "setup" type
> problems and not really conversion problems (acc. infra)
>
> As a maintainer of several servers, I think its normal to think how can we
> do better....I cannot see why I should not raise concerns, when I have
> them, to me an argument about a thing being complicated is not an argument
> for not doing the right thing. Admitted I did not need to write the agency
> part, but I really feel stuck in the discussion.
>
>
>
> The CWiki serves its purpose very well.
>>
>
> I am sure it does, and did not dispute that....I am solely thinking of our
> stretched maintenance resources (including infra), at some point we do need
> to consolidate our information stores.
>
> We have our different www's, different wikis and a blog all containing bits
> and pieces of information, some of it redundant (and often not maintained
> in some of the flavours), on top of that we have the forums.
>
> My point is, independent how difficult it is, we should target a
> consolidated set of information, with a clear signal, where which info is
> kept.
>
>
>
>>> 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?
>>
>
> You already help a lot, thanks for that, and you are right it will be a
> hard job to get it done after a community decision.
>
>>
>> The balance is that the ASF manages Confluence, but the project must
>> manage our own MediaWiki.
>>
>
> I have no opinion on which systems shall survive, if we think CWIKI is the
> better choice then so be it. But please dont forget ASF is you, me and many
> others. What I mean is, when I maintain the servers, its hard to see if I
> wear my AOO cap or my ASF/INFRA cap.
>
>>
>> Since the ASF is considering WordPress as a replacement for Roller. Maybe
>> some of the CWiki content belongs there?
>>
>
> It is at the moment only a infra consideration and test. I have not dared
> suggest it, but WP would be able to handle blog, cwiki, mediawiki and large
> parts of www.
>
>>
>> Anyone object to the deletion of the unused OOODEV cwiki?
>>
>
> +1
>
> rgds
> jan I

I have nothing against deletion.

And I think Jan means the same. ;-)

Marcus


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


Mime
View raw message