Re: move mesos/mesos wiki pages on github into svn

[Adam Monsen <ha...@gmail.com>]

On 03/04/2013 07:45 AM, Mattmann, Chris A (388J) wrote:
> My honest observation here is that this is way too much work for
> documentation :)

I disagree.

I wrote:
> > 1. migrate all pages from http://github.com/mesos/mesos/wiki
> >    into SVN

Already done. Bam! :)

> > 2. move anything wiki-like to a new wiki

This shouldn't be much worse than cutting and pasting... cutting from
Markdown/Textile files in SVN and pasting onto the wiki. Sounds like
there's already a confluence wiki created ( accodrding to
http://incubator.apache.org/projects/mesos.html ).

But of course, the distinction between canonical documentation vs. wiki
documentation is subjective, so maybe everything will just stay in SVN.
At any rate, this doesn't need to be done right away.

> > 3. standardize on one markup language

This is important, IMHO, and can be done automatically using pandoc.

Re: move mesos/mesos wiki pages on github into svn

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Hi Adam,

On 3/4/13 11:31 AM, "Adam Monsen" <ha...@gmail.com> wrote:

>On 03/04/2013 11:15 AM, Mattmann, Chris A (388J) wrote:
>> My point is, if we have to type all of this email around making
>> documentation, then there's a problem. If the barrier to contribute
>> documentation requires 10 different tools, in different places, there
>> is a problem.
>
>I totally agree with your points, Chris!
>
>Was there something specific in what I recommended that you're providing
>constructive criticism of?

Mainly your disagreement to my point about it being way too much work based
on what was outlined for the documentation. I was simply saying KISS
principles
apply :) IOW, reading multiple paragraphs about what had to be done to
update
documentation was worrying me, that's all :)

Seems like you've got it figured out and can contribute, etc., and docs
are 
being produced, and nothing much else to see here, so I'll move right
along.

Cheers,
Chris

P.S. Instead of directly emailing the replier, and then CC'ing the dev
list, I prefer to direct
the TO: part of the message to the dev list. I assume you and Ben H. are
already subscribed to *-dev.

Re: move mesos/mesos wiki pages on github into svn

[Adam Monsen <ha...@gmail.com>]

On 03/04/2013 11:15 AM, Mattmann, Chris A (388J) wrote:
> My point is, if we have to type all of this email around making 
> documentation, then there's a problem. If the barrier to contribute
> documentation requires 10 different tools, in different places, there
> is a problem.

I totally agree with your points, Chris!

Was there something specific in what I recommended that you're providing
constructive criticism of?

My aim is/was to help consolidate the documentation as well as improve it.

Re: move mesos/mesos wiki pages on github into svn

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Adam, TL;DR

My point is, if we have to type all of this email around making
documentation, then
there's a problem. If the barrier to contribute documentation requires 10
different tools, 
in different places, there is a problem.

This is based on my own personal experience, having been at the Foundation
since 2005.

I'll leave it at that.

Chris


On 3/4/13 10:51 AM, "Adam Monsen" <ha...@gmail.com> wrote:

>On 03/04/2013 07:45 AM, Mattmann, Chris A (388J) wrote:
>> My honest observation here is that this is way too much work for
>> documentation :)
>
>I disagree.
>
>I wrote:
>> > 1. migrate all pages from http://github.com/mesos/mesos/wiki
>> >    into SVN
>
>Already done. Bam! :)
>
>> > 2. move anything wiki-like to a new wiki
>
>This shouldn't be much worse than cutting and pasting... cutting from
>Markdown/Textile files in SVN and pasting onto the wiki. Sounds like
>there's already a confluence wiki created ( accodrding to
>http://incubator.apache.org/projects/mesos.html ).
>
>But of course, the distinction between canonical documentation vs. wiki
>documentation is subjective, so maybe everything will just stay in SVN.
>At any rate, this doesn't need to be done right away.
>
>> > 3. standardize on one markup language
>
>This is important, IMHO, and can be done automatically using pandoc.
>