Hello developers and writer, from my side I will help as last year at the German translation for darktable and the German user manual.
It would be nice if there would be a trigger signal when the translations can be started. Does darktable 3.0 have its own branch or is this in master? Is the manual included in the same branch as darktable as in previous versions or is the manual separated? cheers Pierre Am Dienstag, 13. August 2019, 10:47:53 CEST schrieb Matthieu Moy: > ----- 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, ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
