I'll make all the changes in one branch, each commit will become a PR. No more than 2 PRs at a time. If anyone wants to add to the branch, feel free. The branch itself won't become a PR.
On Thu, Sep 17, 2026 at 6:33 AM Richard Zowalla <[email protected]> wrote: > Hi, > > would go for small units and PRs. > Much easier to review, imho. > > Gruß > Richard > > > Am 17.09.2026 um 11:30 schrieb Kristian Rickert <[email protected]>: > > > > Hi Team, > > > > I plan to make a controlled set of updates to the DocBook. To avoid > > flooding our communication channels, I propose the following approach: > > > > - I have created a single branch for all DocBook updates. > > < > https://github.com/apache/opennlp/tree/OPENNLP-1958-docbook-branch-epic> > > - We will create a separate examples module specifically for the > DocBook > > examples. > > - I am currently working out of a branch on my own fork for each > chapter > > (though I am happy to move this to the main repository if preferred). > > - Each chapter will have a single focused commit that we can submit as > a > > PR. I just don't want to flood the PR list. > > > > I can either submit each chapter as an individual PR or combine them > into a > > single ongoing branch/PR - whichever the team prefers I have no strong > > feelings about the workflow. > > > > We will determine how to merge them based on this thread. > > > > I have no strong feelings on the approach. I'll defer to the rest of the > > team regarding how you want the updates merged. > > > > I was an editor for my college paper :) So I promise to edit everything > > well before creating any PR or merging into this branch. I'll have a > > separate branch per PR in my fork. > > > > My motivation stems from renaming a class awhile back. 'Twas good > > refactor, but the book example was stale. Whenever that happens to me on > > the receiving end, I get annoyed. So I'm fixing it. > > > > Doc-bearing, > > > > Kristian >
