Subject: [Teas-ns-dt] A commonly used approach to tracking issues...

From: Eric Gray <[email-masked]>
Date: Thu, 28 May 2020 16:57:52 +0000

Authors/Editors,

We may not need this at this point but, in other large design team efforts, we have found it useful to track at least the major issues using a spreadsheet (or similar "Issues List") approach.

Key things to track:

  *   Text/Context (where the issue occurs in the draft - page, section, and position on the page or in the section);
  *   comment/issue with this text (more usefully descriptive, generally, than "I don't like this text");
  *   current proposed resolution (change text to <...>, remove text, add further clarification text <...>, reject [provide explanation]).

It can also be useful (but not absolutely necessary) to include the name(s) of the person(s) raising the issue, in order to provide a list of who needs to be happy with the resolution.

One way that this helps is that it keeps the need to plow through iteration after iteration of the draft, trying to find where the text is actually changed (or removed) in each iteration.

As a proof of concept related to this, the "diff" that Kiran showed at today's meeting showed a lot of "changed" lines that had actually been moved to some other location - effectively making it look as if a lot more changes had been made than actually were made.

--
Eric

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 28 May 2020 10:01:16 -0700

Guys,

I have been trying to collaborate with you from the beginning, did 3 full reviews, separately with each of you.
Somehow this didn’t work out, it is still you (as a group) and the rest.
Would you want to include me?

Cheers,
Jeff
On May 28, 2020, 9:58 AM -0700, Eric Gray <eric.gray=[email-masked]>, wrote:
> Authors/Editors,
>
> We may not need this at this point but, in other large design team efforts, we have found it useful to track at least the major issues using a spreadsheet (or similar “Issues List”) approach..
>
> Key things to track:
>
> • Text/Context (where the issue occurs in the draft – page, section, and position on the page or in the section);
> • comment/issue with this text (more usefully descriptive, generally, than “I don’t like this text”);
> • current proposed resolution (change text to <…>, remove text, add further clarification text <…>, reject [provide explanation]).
>
>
> As a proof of concept related to this, the “diff” that Kiran showed at today’s meeting showed a lot of “changed” lines that had actually been moved to some other location – effectively making it look as if a lot more changes had been made than actually were made.
>
> --
> Eric
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 29 May 2020 10:30:51 +0900

+1

Spreadsheet (or Excel file put on a folder anyone can access) would be
useful for management/tracking of issues.
# Actually, we might have lost some  issues and comments  raised due to
making new files and sharing them with email.

It would be better to sync up  google docs and spreadsheet by marking issue
number to each changed place.

Regards,

Shunsuke

On Fri, May 29, 2020 at 1:57 AM Eric Gray <[email-masked]> wrote:

> Authors/Editors,
>
>
>
> We may not need this at this point but, in other large design team
> efforts, we have found it useful to track at least the major issues using a
> spreadsheet (or similar “Issues List”) approach.
>
>
>
> Key things to track:
>
>    - Text/Context (where the issue occurs in the draft – page, section,
>    and position on the page or in the section);
>    - comment/issue with this text (more usefully descriptive, generally,
>    than “I don’t like this text”);
>    - current proposed resolution (change text to <…>, remove text, add
>    further clarification text <…>, reject [provide explanation]).
>
>
>
> It can also be useful (but not absolutely necessary) to include the
> name(s) of the person(s) raising the issue, in order to provide a list of
> who needs to be happy with the resolution.
>
>
>
> One way that this helps is that it keeps the need to plow through
> iteration after iteration of the draft, trying to find where the text is
> actually changed (or removed) in each iteration.
>
>
>
> As a proof of concept related to this, the “diff” that Kiran showed at
> today’s meeting showed a lot of “changed” lines that had actually been
> moved to some other location – effectively making it look as if a lot more
> changes had been made than actually were made.
>
>
>
> --
>
> Eric
>