cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Graham <tgra...@tgraham.us>
Subject Re: System VM
Date Fri, 04 Oct 2013 18:24:41 GMT
From the perspective of a new community member being able to contribute to a separate repo
that doesn't touch the app code is nice because that would open up the possibility of being
a committer for the doc repo and separate that silo of work. Also less volatile in the fact
that people, like me, who don't want to or can't mess with the actual Java side of the house
and potentially having to deal with funky rebase issues and keeping up to date in the fast
moving target state that the main code stays in.

There's talk of splitting the Release Manager out into separate roles with one head RM and
sub RM's within their area of responsibility. I think this would help on that front as well.
Having a lead Docs person (I think that's David?) who can oversee the whole process but can
delegate things out to community members who are willing to take on the work.

That's my initial thoughts, I'm sure I could think of more advantages later once I work through
more of the docs process. It's been interesting so far.

Travis

On Oct 4, 2013, at 1:55 PM, Chip Childers <chip.childers@sungard.com> wrote:

> On Fri, Oct 04, 2013 at 05:43:16PM +0000, Jessica Tomechak wrote:
>> Hi guys,
>> Not arguing against it, but I would be very much interested in your reasoning behind
why having docs in a separate repo makes them easier to work on. What have we experienced
since this time last year which has led us to reverse the original decision to keep docs in
the same repo with code?
>> 
>> And having mentioned this, also thanks to y'all for taking care of doing the actual
split and setting up the new repo.
>> 
>> Jessica T.
> 
> Documentation has a different lifecycle from the code, since docs aren't
> usually complete anywhere near feature complete.
> 
> Also, having it in a different repo will help contributors more easily
> work with the documentation.  We are seeing a number of new folks in the
> community that want to help on that front.  
> 
> -chip


Mime
View raw message