On Wed, Feb 13, 2013 at 05:50:22PM +0100, Sebastien Goasguen wrote: > > On Feb 12, 2013, at 8:30 PM, Chip Childers <chip.child...@sungard.com> wrote: > > > On Tue, Feb 12, 2013 at 10:54:42AM -0600, Joe Brockmeier wrote: > >> On Tue, Feb 12, 2013 at 05:25:11PM +0100, Sebastien Goasguen wrote: > >>> After 2/28 we will just fix doc bugs, not add new docs, even if a feature > >>> is included in 4.1 if its docs are not in by 2/28 then too bad. > >> > >> -1 to this. > >> > >> The reason for stopping feature development with a hard freeze is that > >> new features have the potential to disrupt the codebase badly enough > >> that it's a major issue. > >> > >> Adding new docs makes it a problem for translators, but it doesn't carry > >> the same level of disruption as new features. For example, think about > >> the impact if Javelin landed a week later than it did into master vs. > >> the impact of adding another section to the install or admin guide. It's > >> not really comparable. > >> > >> Also - leaving a feature out of a release means it can be picked up in a > >> later release. Failing to document features is, basically, a bug that > >> should be fixed (if possible) before a release. > >> > > > > Unless that feature's lack of documentation effectively just means that > > it's not used (but available). > > > >>> That's a bit of tough love, but that's what will happen if we want to > >>> stick to the schedule. > >> > >> I'd like to stick to the schedule, but we should have more flexibility > >> here than with features. It's also worth noting this is the first > >> time through with a hard feature release and we're still finding our way > >> - and what we seem to be finding is that ~1 month for documentation is a > >> bit tricky when a lot of features land (or don't) right on the feature > >> deadline. > > > > I actually agree with Joe for 4.1.0. Right up until 2013-03-22, but > > only as a way to give our docs folks a bit more time to catch up. The > > more that's done earlier the better. The implication of this is that > > our translations will suffer (i.e., not be done). > > > > We could have a post-release translation update planned, since the > > published docs site doesn't have to be part of a release officially. > > BTW, do we have anything beyond en-US published to the website anyway? > > If not, we should! > > > > All that being said, I think that we need to work out a better schedule / > > plan for the > > next feature release. I think back to the discussions about the schedule, > > and a general desire to consider "done" for a feature as meaning "coded, > > tested, documented". Perhaps that has to become the criteria for next time? > > I am fine with this, but I'd like to see the schedule updated (otherwise it > becomes meaningless). > It's not an issue of translations, it's really an issue of procedure and > schedule. > > On the docs release, I think we need to have yet another thread :(. Docs code > is part of a release, but we may get updates prior to a bug fix release. It > would be good to be able to release new docs continuously. ( Jessica had > started a thread about this). > > -sebastien
Joe mentioned trying to organize a docs sprint during the irc meeting. Ideally, we would avoid any schedule change, but I've updated the release plan to reflect the fact that docs are not a hard freeze. -chip
