Apologies for the misspelling, Mattieu. ---------- Forwarded message --------- From: Bruce Williams <stu...@audio2u.com> Date: Tue., 13 Aug. 2019, 15:23 Subject: Fwd: [darktable-dev] Feature freeze for 3.0 To: darktable <darktable-dev@lists.darktable.org>
I wholeheartedly agree with Matthew on the documentation front. Now, I'll confess, I couldn't write a line of code if my life depended on it! Nor could I reverse-engineer anything. But, writing copy has been part of my career (as a radio promo producer) for the last 30+ years. If the guys writing the new features are prepared to write draft notes on how a certain new feature works, I would be happy to help with the copy editing for the 3.0 documentation. Cheers, Bruce Williams. ---------- Forwarded message --------- From: Matthieu Moy <li...@matthieu-moy.fr> Date: Tue., 13 Aug. 2019, 14:34 Subject: Re: [darktable-dev] Feature freeze for 3.0 To: Pascal Obry <pas...@obry.net> Cc: darktable <darktable-dev@lists.darktable.org> ----- Original Message ----- > From: "Pascal Obry" <pas...@obry.net> > Also, to avoid the hard work at the end of year (like in 2018) I'd like > to have a feature freeze earlier. I support this. We had a lot of last-minutes fixes last years, and given the amount of changes, we really need a long testing period this year. > My current plan is: > - *feature* freeze end of September > > - *strings* freeze end of October > > - *RC0* end of October > > - *RC1* end of November I'd like to raise another point: the manual. The dt tradition is to make the release, and complete the manual afterwards. This has disadvantages for several kinds of people: 1. Users are somehow frustrated to get a nice release without the full documentation. I could live with this, but there's also: 2. People writing articles about the release (e.g. myself) have a hard time reverse-engineering the changes. Last year's release notes were better than the previous ones for me, but still much more work to understand than a proper user-manual. 3. Testers cannot really test without the manual. This is related to point 2: last year I reported a lot of bugs found while trying to understand how new features worked, but without the documentation one doesn't know what to test, nor what's the expected behavior. 4. People proof-reading the documentation, which can be the same as 2. For example, the manual doesn't seem to document the hierarchical tags shortcuts (control/shift double-click) in the collect module while they are documented in my article (https://www.darktable.org/2018/12/darktable-26/). I would happily report bugs for missing documentation, but when I do so I usually get "please be patient, we'll write the doc later" as an answer, so I don't report these bugs. To me, the ideal flow is to write at least a draft of the doc in the same PR as the code (which does help a lot with points 3. and 4. since testing is also important before merging), but having the manual ready before the release (e.g. not too long after the feature freeze or string freeze in your list above) would greatly help. > Thanks to all people involved in this release, it is amassing to see > the developer community to grow! Indeed, last year was awesome, this year seems even awesomer (I know, the word doesn't exist, but if it did it would apply here) ;-). Cheers, -- Matthieu Moy https://matthieu-moy.fr/ ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
