To add my two-cents, since I missed the party earlier, by way of example from my own use cases. On my team every sprint/cycle we create an over-arching "tech debt" epic which we close out at the end of the sprint. Usually there is some tech debt that requires doing and a Jira task(s) is created under this epic. For us updating/amending docs is part of tech debt and it informs the larger picture of things - usually it means something was missed. Updating of docs is usually part the Jira story (a separate task) for the code that corresponds to the docs and is considered as part of meeting the "definition of done".
For Geode, unless there is a new feature/enhancement/bug-fix being done then there's a large quota of tech debt so creating an epic "tech debt" and having numerous Jira tasks under it to cleanly tie in what was done for a particular sprint. Doc changes would just fall inline as we know this is a period of transition for Geode so there could be a number of tech debt checkins that just include docs or more usually code and docs. Sensibly things like typos can be consolidated into a single jira and then put up for review and merged at the end of the cycle - assuming these typos can't b done as part of some other checkin. Typos in themselves aren't usually an urgent and necesary need like a bug-fix that may have to go in pronto. Either way I think the policy should be set and everyone ack and abide and move on for smooth sailing. On Mon, Feb 29, 2016 at 6:25 PM, Dave Barnes <[email protected]> wrote: > Based on some off-line discussions, as well as this thread, I'm buying into > the idea that all changes should follow the same rules. It's simpler that > way and the additional overhead of crafting a JIRA ticket is minimal, > really. [I'm assuming we won't run out of JIRA numbers anytime soon...] > > > On Mon, Feb 29, 2016 at 3:20 PM, Jens Deppe <[email protected]> wrote: > > > For things like 'doc typos' we could consider a Jira that remains open > for > > a specific release or period of development and then gets closed at the > end > > of that cycle. > > > > On Mon, Feb 29, 2016 at 1:55 PM, Kenneth Howe <[email protected]> wrote: > > > > > +1 to Jake’s comment > > > > > > The number of “special cases” we’re talking about is pretty small > > compared > > > to the overall number commits. Even for doc typos it’s not a problem to > > > submit a JIRA when you see the problem. I’d be inclined to open one > JIRA > > > for however many typos or minor textual errors I find on a read-through > > or > > > review of a doc. > > > > > > Ken > > > > > > > On Feb 29, 2016, at 1:42 PM, Dave Barnes <[email protected]> wrote: > > > > > > > > I withdraw the re-usable JIRA ticket suggestion - it was > semi-facetious > > > > anyway. > > > > > > > > On Mon, Feb 29, 2016 at 1:33 PM, Jacob Barrett <[email protected]> > > > wrote: > > > > > > > >> +1 > > > >> > > > >> All changes in the repo should have a ticket. > > > >> > > > >> On Mon, Feb 29, 2016 at 11:21 AM Udo Kohlmeyer < > [email protected] > > > > > > >> wrote: > > > >> > > > >>> My opinion is that no work should be done without a JIRA. That way > > > there > > > >>> is a "documentation" on what the task is and you can measure the > > > outcome > > > >>> based on the JIRA. > > > >>> > > > >>> One might think that one could end up in a scenario where we'd end > up > > > >>> creating JIRA's for the sake of creating JIRA's. But in the long > run > > > >>> those "trivial" tasks become less frequent. > > > >>> > > > >>> I also thought that there was some unwritten rule that no changes > > shall > > > >>> be made directly in trunk/develop? ;) > > > >>> > > > >>> > > > >>> > > > >>> On 1/03/2016 6:05 am, Dan Smith wrote: > > > >>>> My opinion is that docs and minor changes to tests or build > scripts > > > >> don't > > > >>>> need necessarily a JIRA. So I'm not sure we want to enforce this > > with > > > a > > > >>>> hook. > > > >>>> > > > >>>> That said, I definitely see commits in the log that look like > > product > > > >> bug > > > >>>> fixes, and I totally agree those should have ticket #s in the > > commit. > > > >>>> > > > >>>> Jason suggested something that I think might be a good idea - for > > > >> changes > > > >>>> that don't need a JIRA, maybe we can put some other tag in that > > spot. > > > >> For > > > >>>> example: > > > >>>> > > > >>>> DOCS: Update most occurrences of "Geode" to "Apache Geode". > > > >>>> > > > >>>> -Dan > > > >>>> > > > >>>> On Fri, Feb 26, 2016 at 6:34 PM, kareem shabazz < > > > >>> [email protected]> > > > >>>> wrote: > > > >>>> > > > >>>>> Is it by design that there are no client-side Git hooks to > prevent > > > >> this > > > >>>>> sort of thing? > > > >>>>> > > > >>>>> -- > > > >>>>> Kareem > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Fri, Feb 26, 2016 at 10:36 AM -0800, "Kirk Lund" < > > > [email protected] > > > >>> > > > >>>>> wrote: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Please remember to include the GEODE-xxx jira ticket # in your > > commit > > > >>>>> messages. I'm looking at git log on develop and I can't correlate > > > >>> several > > > >>>>> checkins with any jira tickets. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Kirk > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>> > > > >>> > > > >> > > > > > > > > > -- Kareem
