incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?
Date Thu, 15 Sep 2011 20:45:11 GMT
On Thu, Sep 15, 2011 at 12:30 PM, Rob Weir <robweir@apache.org> wrote:

> On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier <tjfrazier@cfl.rr.com> wrote:
> > On 9/6/2011 18:12, Rob Weir wrote:
> >>
> >> Moving this point to its own thread
> >>
> >> On Tue, Sep 6, 2011 at 6:03 PM, drew<drew@baseanswers.com>  wrote:
> >>>
> >>> On Tue, 2011-09-06 at 17:30 -0400, TJ Frazier wrote:
> >>>>
> >>>> On 9/6/2011 13:43, Matt Richards wrote:
> >>>>>
> >>>>> Well, I thought Terry has resigned from the project according to
> >>>>> another
> >>>>> thread, leaving the wiki migration at a bit of a stand still. Figured
> I
> >>>>> could step in and pick up where he left off on this. Am I able to,
as
> a
> >>>>> non-contributor reach out to Apache Infra on this (from what I read
> it
> >>>>> seems
> >>>>> the infra ML are for existing contributors only)? Not sure who all
is
> >>>>> involved at this point.
> >>>>
> >>>> As Pedro commented, you don't need a newbie to help with the
> conversion.
> >>>> But in the long run, I volunteer to learn whatever is needed to
> support
> >>>> the MW system. All I have to offer is that I am a sysop on the live
> >>>> wiki,
> >
> > <snip>
> >>
> >> Another option to consider is that of content translation: MediaWiki
> >> to Confluence.  Remember. Confluence is fully supported by Apache
> >> Infra.  We would also find a lot of people on the list who could help
> >> write and test wiki text conversion code.  It is just string
> >> manipulation, right?  How hard can that be?  Even I can help with
> >> that.
> >>
> >> But seriously, the MW plans were always precarious.  We did not have a
> >> deep bench of expertise on the sys admin side of that package.  Even
> >> if we have a volunteer or two step in now, aren't we still rather
> >> thin?  Wouldn't we still be one "life change" away from being back
> >> where we are now?  But if we can figure out a content-level migration
> >> to Confluence wiki, then we would have something much more sustainable
> >> long term.
> >>
> >> Just an idea.
> >>
> >> -Rob
> >>
> > My question is, "Is it worth looking at Confluence Wiki /at all?/ "
> >
> > Q: Why does everybody use Cwiki?
> > A: Infra supports it.
> > Q: Why does Infra support Cwiki?
> > A: Everybody uses it.
> > Hmm. "Very interesting," as Arte Johnson used to say.
> >
>
> This is true, but there is more here than may be immediately evident.
>
> The fact that a service is widely supported by Apache Infra is very
> important.  Remember, we no longer have Oracle's full-time web admin
> staff to mind the OOo severs.  We'll soon be independent of that and
> Apache will be responsible for routine maintenance, upgrades as well
> as responding to problems.
>
> And we must not underestimate the potential for problems.  Apache is a
> high profile target. So is OpenOffice. Mix them together and the
> question is not "if" someone will attack our website and try to take
> it down.  The question is "when?".
>
> I don't say that to scare you.  Just to point out reality.
>
> It is worth looking back at the note from Mark Thomas [1] sent to the
> list back in July, to understand what it means to be using an
> unsupported server app at Apache:
>
> "The much more important question is who will support it. There have
> been far too many examples of projects requesting a service, promising
> to help support it and then never being heard from again when it needs
> maintenance. If the current maintenance is performed by Oracle rather
> than the community there will be concerns about the viability of that
> model.
>
> On a related note, infrastructure will not tolerate project managed
> systems that are insecure. We will shut them down first and ask
> questions later. Projects are expected to keep on top of security for
> the services that they manage. We do arrange things so projects can
> only shoot themselves in the foot but will still expect security to be
> maintained. "
>
> I fully acknowledge that moving to CWiki would result in an imperfect
> translation of the content that will take additional effort to clean
> up.  And that moving to MWiki will be faster.  But we only need to
> migrate once, right?  But we need to maintain this for the next 10
> years.  That is why I talked about CWiki being "more sustainable".
> Sure, it is pain now.  But we'll have much more help at Apache going
> forward if we're using the same software that everyone else uses.  If
> we use MWiki, we may migrate faster, but we'll be shut down at the
> first sign of a problem.
>
> I'm not saying the MWiki is unworkable.  But if we really want this to
> work, long term, then we should be looking to have a solid base of
> admin experience to help maintain it in the long term.  Not just help
> migrating, but longer term.  And not just one person, but maybe 3
> people who know it well and another 2 who can start learning it now.
> Remember, the OOo wiki was not just a little thing on the fringes of
> the project.  It was at the center of how the project was run.  Having
> a sustainable wiki is essential for the AOOo project.
>
> [1] http://markmail.org/message/b23uko3fro5ijqkz
>
>
> -Rob
>

So....what's the status of the basic info port from MW to cwiki right now?
Any news?

Yeah--the template conversion dos look a bit hairy, and since I know NOTHING
about this at all, well, who knows.

TJ's somewhat correct in the help aspects, but I find the help available to
the project now using cwiki not bad actually. The User Guide for Confluence
is HUGE but really, I don't know how many more advanced aspects would be
needed or used by 90% of the users.


>
> > *Personal gripes.*
> > My biggest gripe with Cwiki is the help; the file is neither searchable
> nor
> > editable (do that in Mwiki to see how an example /really/ works); it is
> also
> > in need of some serious editing. (To be fair, I have not yet explored
> their
> > User Guide, but I will.) It is not clear to me that Apache users are best
> > served by Confluence.
> >
> > *Conversion problems.*
> > Terry sized this as "man-years of effort". I agree.
> > Going the other way (Cwiki to Mwiki) should be, as Rob wrote, "just
> string
> > manipulation", because MW is richer in features than CW, so a good
> > translation possibility exists. It may not exist in reverse.
> >
> > One big snag is the MW templates, which are used for everything from
> > copyright attribution to inter-page tables of contents. Given that the
> > output of any MW artifact is displayable HTML, it is /possible/ to
> convert
> > to a CW page that looks exactly like the MW page. However, offering the
> > functionality of being able to add a line to a TOC template, and have
> > everything else happen automatically ... that's hard. (Please note that
> > 'possible' != 'reasonable'.)
> >
> > Then there are smaller things, like sortable tables (on all columns,
> too!).
> > In MW, that's 'class = "prettytable"' -> 'class = "prettytable
> sortable"';
> > just add the one word. <snide> Can CW do it at all? </snide>
> >
> > The <math> ... </math> feature is of some use in explaining the more
> > abstruse Calc functions (in FAQ pages). The major user is the Math
> Guide's
> > wiki version. (I maintain that document.) Not really an essential
> element,
> > but nice.
> >
> > I have little doubt that a serious conversion survey will turn up a
> number
> > of such problems.
> >
> > *Migration problems.*
> > There are some technical problems with the migration (that is, running MW
> at
> > Apache); most of those appear to have short- and long-term solutions. I
> will
> > save the details for a more technical thread, and/or the wiki.
> > --
> > /tj/
> >
> >
>



-- 
---------------------------------------------------------------------------------------
MzK

"There's something about the sound of a train
 that's very romantic and nostalgic and hopeful."
                               -- Paul Simon

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message