On dinsdag 2 mei 2017 18:10:35 CEST David T. via gnucash-devel wrote: > Here’s what I mean: > > On the Documentation Update instructions, section 3 contains 17 different > steps. > > Step 3.1: Create a Bugzilla Bug is a step that should be undertaken with > every proposed change to the documentation. > > Step 3.2: Clone the Documentation, however, is (presumably) a one-time > setup. Steps 3.3-3.5 similarly are one-time setups (unless you’re a screwup > like me, and then you get to do them over and over again). > > Steps 3.6-3.10 are again repeated for each change to the docs. > > Step 3.11 is a step that is not technically part of the documentation > process at all, since it only applies to one family of GnuCash’s supported > operating systems. Mac and Windows writers don’t perform this step, and the > fact that I have been contributing changes for years without conducting > these tests underscores the fact that they aren’t a required part of the > Documentation Update process. > > Steps 3.12 and following are back to steps taken on each change—although at > this point, I wonder whether people are preparing patches and attaching > them to Bugzilla bugs (steps 3.15-3.17), or whether everyone has moved to > the Github pull request method. >
I believe you make a valid point. The current structure makes it more difficult than necessary to find what you should do next while working on documentation. IMO would make more sense to have a section "prepare your environment" with the details of one time actions and a section on what's needed the handle one specific bug. Optionally a section on how to clean up if things went wrong or when switching to another bug to work on. I didn't follow the discussion in the past in detail I'm afraid so I don't know why this or something similar wasn't taken into consideration. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
