Subject: [netmod] keeping track of proposed changes

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 09:48:24 +0200

Hi,

my question may follow from the fact that I have little experience with
IETF working group workflows, but anyway: quite a few proposals for
changes in YANG etc. have been raised and discussed in the mailing list
but I am not sure - does anyone keep track of them and how will they be
resolved? Perhaps we should enter them into a request tracker?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Jun 2008 11:08:22 -0700

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "NETMOD Working Group" <[email-masked]>
> Sent: Thursday, June 05, 2008 12:48 AM
> Subject: [netmod] keeping track of proposed changes
...
> resolved? Perhaps we should enter them into a request tracker?
...

There appears to already be an issue tracker for netmod -
see http://www3.tools.ietf.org/wg/netmod/trac/report/1

Randy

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Jun 2008 10:05:16 -0400

Hi,

There is an issues tracker available for netmod.
See http://www3.tools.ietf.org/wg/netmod/trac/report/1

I have not decided how it should be used, and have not discussed this
with DavidP yet.

Generally, it is the editor of a document that keeps track of
requested and proposed changes to the document, preferably with an
change log and an open issues list as appendices in the document.
Editors generally are empowered to determine consensus regarding
proposed changes to their document. The chairs have the responsibility
to ensure that editors are being fair and open, and when we submit
documents to the AD/IESG, we sometimes need to be able to point to the
discussions and where consensus was reached, to "prove" we had a fair
and open process, and to deal with potential appeals. An issues
tracker is also useful for "closing" discussions that could go on
endlessly.

So the issue tracker would also be useful for the chairs to be able to
document consensus, focus conversations, and declare a topic closed.

I created a ticket for one thread to experiment with the tracker. We
can do this for subsequent threads if desired. I started this issue
before we had an controversy, simply documenting "this was discussed
here", and the chairs can go into the thread-tracker and document
where consensus was reached in a thread. I am not sure this is a good
approach however, because the issues are not necessarily clearly
defined when a thread starts, and a thread might bloom into mulitple
issues, and never reach any consensus. If we try to track too much, we
may create information overload. 

For previous WGs I co-chaired, I tried using the issue stracker for
all the requested changes, including aggregations of editorial
corrections. I found this to be a problem. There is significant
overhead in tracking every change and having to maintain a database of
the requests. We already have a formal venue for requestng changes -
the mailing list. To track an issue that is raised on the list in the
tracker means copying the request from email into the tracker, and
copying "significant" subsequent discussion of the issue into the
tracler as well. Then there are two parallel discussions that become
hard to keep in sync without a lot of work. So, I think the issue
tracker should be used for "issues", not all proposed changes.

The way I would like to track proposed changes is to have the editors
keep their own proposed change logs, which may include many small
editorial changes. This allows the editors to organize their work in a
manner thay find comfortable. I keep mine in folders for each
document, and flag the ones I have yet to address in the document, and
clear the flag after I make the chnage. This is easy for me as an
editor. The documents should have a change log summarizing the changes
that have been made. 

We should track issues where documenting consensus is important. The
editors can determine fairly easily which proposed changes require
them to think about "what is the consensus on this?" and those that do
not. As issues arise that require the editor to judge consensus, the
editor should have them documented in the issues tracker. If issues
arise where the editor is not sure he understands the edits, he can
have that documented in the tracker.  If an issue is not yet resolved
when a new draft is published, the "open issues" should be mentioned
in an appendix.

The chairs (and possibly editors) can also document significant
threads to discuss technical alternatives and choose a resolution. The
chairs will watch for these, but WG members can also request that an
issue be documented. The chairs can decide something does not deserve
a ticket. 

The editors should be prepared to create and post a list of open and
resolved issues when requested by the chairs, and should be prepared
to discuss the current status of issues when we have an IETF session.
The issues tracker certainly should be helpful to the editors for this
purpose.

Does this sound reasonable?

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Thursday, June 05, 2008 2:08 PM
> To: NETMOD Working Group
> Subject: Re: [netmod] keeping track of proposed changes
> 
> Hi -
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Jun 2008 14:26:24 +0200

Hi Dave,

another benefit of an issue tracker is that everyone who wants to start
a thread can browse the previous tickets to see whether the same or
related issue has already been addressed.

In any case, I suggest to use the tracker also for issues that are
considered bugs - although the notion of a bug is subjective, too. But
at least mistakes and ommisions spotted in the drafts should go there.

With respect to the problem of using a tracker versus mailing list,
I asked my colleagues from the CSIRT team who have to deal with the same
problem about their solution - they have an issue tracker integrated
with a mailing list so that every incoming email is automatically
entered into the tracker.

>From your previous test ticket I understand that the tracker sends an
email to the list when a new ticket is created. I am not able to find in
th etracker though whether it is possible to register for obtaining
notifications wrt a concrete issue. These two things should be enough
for the folks interested in a given ticket to get informed and involved.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C