Re: [DISCUSS] push minor doc improvements/additions directly to release branches
+1! -- ,,,^..^,,, On Thu, Sep 26, 2013 at 2:00 PM, Jan Lehnardt wrote: > +1 > > On Sep 25, 2013, at 23:34 , Dirkjan Ochtman wrote: > >> On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: >>> Would there be any objections to pushing minor doc fixes & additions >>> directly to master? >> >> No! In fact, I was doing that already even before 1.3.1 came out, I think. >> >>> The quicker we can get updates out into docs.couchdb.org, the better. >>> >>> To be clear, I'm not suggesting that major changes like Alex's branch >>> should just go straight in. >> >> We talked about this in IRC today, but I'll reiterate here for those >> who missed that: I think Alex's work on the docs branch is awesome, >> but I feel like the branch has dragged on for way too long. This means >> uncounted users have gotten worse documentation than they could have >> gotten, because we were still tweaking some little thing or not quite >> satisfied with the language somewhere. While this kind of thing can be >> unavoidable with code, where there's much more complexity to deal >> with, documentation isn't like that, and we shouldn't treat it like >> that. Documentation patches should go straight to master or on very >> short-lived feature branches. >> >> Cheers, >> >> Dirkjan >
Re: [DISCUSS] push minor doc improvements/additions directly to release branches
+1 On Sep 25, 2013, at 23:34 , Dirkjan Ochtman wrote: > On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: >> Would there be any objections to pushing minor doc fixes & additions >> directly to master? > > No! In fact, I was doing that already even before 1.3.1 came out, I think. > >> The quicker we can get updates out into docs.couchdb.org, the better. >> >> To be clear, I'm not suggesting that major changes like Alex's branch should >> just go straight in. > > We talked about this in IRC today, but I'll reiterate here for those > who missed that: I think Alex's work on the docs branch is awesome, > but I feel like the branch has dragged on for way too long. This means > uncounted users have gotten worse documentation than they could have > gotten, because we were still tweaking some little thing or not quite > satisfied with the language somewhere. While this kind of thing can be > unavoidable with code, where there's much more complexity to deal > with, documentation isn't like that, and we shouldn't treat it like > that. Documentation patches should go straight to master or on very > short-lived feature branches. > > Cheers, > > Dirkjan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DISCUSS] push minor doc improvements/additions directly to release branches
+1. Docs with minor issues trumps bad docs. On Thu, Sep 26, 2013 at 10:57 AM, Garren Smith wrote: > +1 I agree, SHIP ALL THE DOCS > > > On 25 Sep 2013, at 11:46 PM, Dave Cottlehuber wrote: > > >> On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: > >>> Would there be any objections to pushing minor doc fixes & additions > directly to master? > >> > >> No! In fact, I was doing that already even before 1.3.1 came out, I > think. > >> > >>> The quicker we can get updates out into docs.couchdb.org, the better. > >>> > >>> To be clear, I'm not suggesting that major changes like Alex's branch > should just go straight in. > >> > >> We talked about this in IRC today, but I'll reiterate here for those > >> who missed that: I think Alex's work on the docs branch is awesome, > >> but I feel like the branch has dragged on for way too long. This means > >> uncounted users have gotten worse documentation than they could have > >> gotten, because we were still tweaking some little thing or not quite > >> satisfied with the language somewhere. While this kind of thing can be > >> unavoidable with code, where there's much more complexity to deal > >> with, documentation isn't like that, and we shouldn't treat it like > >> that. Documentation patches should go straight to master or on very > >> short-lived feature branches. > >> > >> Cheers, > >> > >> Dirkjan > >> > > > > +1 to that. Dirkjan's right, and it's past time for the superb work Alex > has put in to make the light of day :-) > > > > SHIP ALL THE DOCS! > > > > > > -- Octavian Damiean GitHub: https://github.com/mainerror
Re: [DISCUSS] push minor doc improvements/additions directly to release branches
+1 I agree, SHIP ALL THE DOCS On 25 Sep 2013, at 11:46 PM, Dave Cottlehuber wrote: >> On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: >>> Would there be any objections to pushing minor doc fixes & additions >>> directly to master? >> >> No! In fact, I was doing that already even before 1.3.1 came out, I think. >> >>> The quicker we can get updates out into docs.couchdb.org, the better. >>> >>> To be clear, I'm not suggesting that major changes like Alex's branch >>> should just go straight in. >> >> We talked about this in IRC today, but I'll reiterate here for those >> who missed that: I think Alex's work on the docs branch is awesome, >> but I feel like the branch has dragged on for way too long. This means >> uncounted users have gotten worse documentation than they could have >> gotten, because we were still tweaking some little thing or not quite >> satisfied with the language somewhere. While this kind of thing can be >> unavoidable with code, where there's much more complexity to deal >> with, documentation isn't like that, and we shouldn't treat it like >> that. Documentation patches should go straight to master or on very >> short-lived feature branches. >> >> Cheers, >> >> Dirkjan >> > > +1 to that. Dirkjan's right, and it's past time for the superb work Alex has > put in to make the light of day :-) > > SHIP ALL THE DOCS! > >
Re: [DISCUSS] push minor doc improvements/additions directly to release branches
>On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: >> Would there be any objections to pushing minor doc fixes & additions >> directly to master? > >No! In fact, I was doing that already even before 1.3.1 came out, I think. > >> The quicker we can get updates out into docs.couchdb.org, the better. >> >> To be clear, I'm not suggesting that major changes like Alex's branch should >> just go straight in. > >We talked about this in IRC today, but I'll reiterate here for those >who missed that: I think Alex's work on the docs branch is awesome, >but I feel like the branch has dragged on for way too long. This means >uncounted users have gotten worse documentation than they could have >gotten, because we were still tweaking some little thing or not quite >satisfied with the language somewhere. While this kind of thing can be >unavoidable with code, where there's much more complexity to deal >with, documentation isn't like that, and we shouldn't treat it like >that. Documentation patches should go straight to master or on very >short-lived feature branches. > >Cheers, > >Dirkjan > +1 to that. Dirkjan's right, and it's past time for the superb work Alex has put in to make the light of day :-) SHIP ALL THE DOCS!
Re: [DISCUSS] push minor doc improvements/additions directly to release branches
On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote: > Would there be any objections to pushing minor doc fixes & additions directly > to master? No! In fact, I was doing that already even before 1.3.1 came out, I think. > The quicker we can get updates out into docs.couchdb.org, the better. > > To be clear, I'm not suggesting that major changes like Alex's branch should > just go straight in. We talked about this in IRC today, but I'll reiterate here for those who missed that: I think Alex's work on the docs branch is awesome, but I feel like the branch has dragged on for way too long. This means uncounted users have gotten worse documentation than they could have gotten, because we were still tweaking some little thing or not quite satisfied with the language somewhere. While this kind of thing can be unavoidable with code, where there's much more complexity to deal with, documentation isn't like that, and we shouldn't treat it like that. Documentation patches should go straight to master or on very short-lived feature branches. Cheers, Dirkjan
