On 18 July 2013 23:31, Rob Weir <robw...@apache.org> wrote: > On Thu, Jul 18, 2013 at 2:41 PM, janI <j...@apache.org> wrote: > > On 18 July 2013 20:12, 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. > >> > > > > 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-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 > >
