What I _think_ you are suggesting is using C-T-R (commit-then-review) [1] for reasonably well-defined documentation-related changes. Do you agree?
Here’s why we tag commits with a JIRA: - we can better understand the reason for a code change by looking at the associated JIRA - we can scope work in/out of a release by using ‘Fix version’ on the JIRA - we can generate release notes by looking at resolved issues for a given version I don’t see much value in creating an uber-JIRA for tracking minor doc changes. Why not skip it entirely? Anthony [1] https://www.apache.org/foundation/glossary.html#CommitThenReview <https://www.apache.org/foundation/glossary.html#CommitThenReview> > On Oct 25, 2016, at 5:45 PM, Karen Miller <kmil...@apache.org> wrote: > > With our documentation now in the same repository as the code, there are now > some doc-related issues that could use some community consensus. Here are > some of my opinions to start the discussion. > > 1. Create new JIRA tickets for each documentation task, or use the existing > ticket under > which the code is committed for the documentation task? > > I'd like to see a combination of both, but use the existing ticket > wherever > possible. By using the same ticket as the code, the documentation effort is > less > likely to be forgotten. I certainly think that when a new property is > introduced, > or a default value is changed, the same ticket can be used. > > I think that for large, and new efforts (in the documentation), new > tickets are the > way to go. > > 2. Do we need a review effort for all documentation tasks? > > My opinion: no, not for everything. The bigger the changes, the more > likely that > a review is warranted. > > 3. Do we need a new JIRA ticket for each very little documentation change? > > On this question, my strong opinion is no, we don't need distinct JIRAs. > I'd like to propose that we use a single ticket per release that > all typo fixes and really small changes are committed under. No > reviews needed. We won't end up with dozens of tickets, each for a tiny > change that really needs no community discussion. If the ticket becomes > abused, > we can revisit the topic. > > I've already created https://issues.apache.org/jira/browse/GEODE-2036 for > just this purpose, as I have a typo that I want to fix. If no one objects, > we can > use this ticket for all tiny fixes that go with Geode 1.1.0.
