As long as it's documented how to update the web site, and we have
something on the web site that tells people how they can submit corrections
/ help out, then this sounds reasonable to me.
That said, I'm not convinced the Wiki should go away completely. I wonder
if we should just port over the most important / core pages, like How to
Contribute, etc. There is a lot of content on the Wiki, historical and
otherwise. Seems like a big job to port it over.
On Tue, Dec 11, 2012 at 10:22 AM, Brock Noland <[EMAIL PROTECTED]> wrote:
> "...which will be released sometime, we'll get not so much content."
> Using CMS patches would result in website changes as soon as they are
> On Tue, Dec 11, 2012 at 12:20 PM, Alexander Alten-Lorenz
> <[EMAIL PROTECTED]> wrote:
> > HI,
> > A website, maintained through patches is in my eyes a overkill. A wiki
> is a living organism, someone can add receipts, best practices and such
> things. Others can review and work on it (if they have access). When a
> contributor has to submit a patch for a website, which will be released
> sometime, we'll get not so much content.
> > - Alex
> > On Dec 11, 2012, at 6:58 PM, Brock Noland <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >> I agree with the dislike of the split between the website and the
> >> wiki. I'd prefer we have all documentation on the website. Is anyone
> >> opposed to moving in that direction? Regarding access, users can of
> >> course submit patches as normal to update the website.
> >> Brock
> >> On Thu, Dec 6, 2012 at 11:28 AM, Ralph Goers <
> [EMAIL PROTECTED]> wrote:
> >>> On Dec 6, 2012, at 4:27 AM, Brock Noland wrote:
> >>>> Hi,
> >>>> At present I feel like our documentation is split half way between the
> >>>> wiki and the website. What are the guidelines as to what goes on the
> >>>> wiki vs the website?
> >>>> FWIW, I am fan of the MRUnit website(http://mrunit.apache.org/). Note
> >>>> that I did not create it! :) It has the "How to Release", "How to edit
> >>>> the website", right on the website itself. Updating it is not very
> >>>> hard because MRUnit uses CMS as Flume does.
> >>> The issue is about control. The wiki is supposed to be open for
> anyone to edit while the web site can only be updated by committers. I've
> said several times that I'm not a fan of having the user's guide and
> developer's guide in the source code. I would much prefer that they are
> directly on the web site and edited in the CMS.
> >>> One thing I don't care for in the mrunit site is that some of the site
> content is on the wiki. I am not a fan of web sites that have you click on
> a link and you are somewhere else and all the site navigation is gone. If
> they want to show wiki content they should do it in an iframe.
> >>> Although I developed the web site in RST I did that because that is
> what was chosen for the User's Guide and Developer's Guide. It wasn't
> really designed to develop web sites although it does a decent job.
> Personally, I'd convert all of it to something more CMS friendly which is
> also compatible with the Maven PDF plugin so it is easy to generate the
> guides from the CMS content at any time.
> >>> Ralph
> >> --
> >> Apache MRUnit - Unit testing MapReduce -
> > --
> > Alexander Alten-Lorenz
> > http://mapredit.blogspot.com
> > German Hadoop LinkedIn Group: http://goo.gl/N8pCF
> Apache MRUnit - Unit testing MapReduce -