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.child...@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
