Ok, maybe we should go with the same kind of thing as with the core code - post a patch for big changes, and just go for it if it's just a little spelling or punctuation fix or similar. My main concern is/was not getting into major merge conflicts if there are two people doing writing a section at the same time, which seems very unlikely given the excellent state that the guide is already in.
On Thu, Jan 16, 2014 at 7:12 PM, Josh Wills <[email protected]> wrote: > I'm still good with commit-then-review for the website, although we have > slowly moved towards more reviews of code over time as the project has > grown. > > > On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <[email protected]>wrote: > >> Hi Josh (and others), >> >> I was wondering if you had any preferences on how we go about handling >> changes to the User Guide (and website content in general). Is there a >> preference to go with a review-then-commit workflow, or >> commit-then-review (or something else)? >> >> I'm assuming that at this point that there won't be any huge major >> additions to it, but I figure it wouldn't be bad to have a general >> agreement on how we want to handle editing it. FWIW, up until now the >> (very minor) changes I've made have just been going straight in >> without any review. >> >> - Gabriel >> > > > > -- > Director of Data Science > Cloudera <http://www.cloudera.com> > Twitter: @josh_wills <http://twitter.com/josh_wills>
