openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Structure of the CWiki?
Date Thu, 18 Jul 2013 22:47:17 GMT
On 18 July 2013 23:31, Rob Weir <robweir@apache.org> wrote:

> On Thu, Jul 18, 2013 at 2:41 PM, janI <jani@apache.org> wrote:
> > 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.
> >
>
> No one ever said you shouldn't raise concerns.  To me it looked like
> you self-censored yourself when you said you "wont press further ".
>
> But you do overstate things when you express them in absolute terms,
> e.g., saying this is about "doing the right thing".  Remember, there
> are many "right things" any of us could be doing in the project (or
> elsewhere), but there are only 24 hours in the day.  This necessarily
> leads to prioritization.
>
> Migrating existing, perfectly good content from one technical
> infrastructure to another is not high on my personal list of
> priorities.  This, however, should not inhibit you are anyone else
> interested from exploring this further. The direction is set by those
> who think something is important, not by those, like myself, who are
> indifferent.
>

you are completly right...."doing the right them" was solely from a
maintenance perspective I should have added that.

its just I am getting a bit tired of doing tiresome maintenance, when I
could use the same time to bring us forward (even though I am not sure what
the target is).

rgds
jan I.

>
> Regards,
>
> -Rob
>
> >
> >
> > 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
> >
> >>
> >> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message