Process change review and approval by fresh eyes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Using my newtrk post as a springboard for a more generic issue:

As Harald said on the plenary, it seems more or less required to create a mechanism where certain process changes could be approved and reviewed without conflicting seriously with the "technical day-to-day job" (as Bert said) and a conflict of interest.

That is, such decisions shouldn't need to be done by the IESG. IAB might be an easy choice, in the absence of anything else readily available..

I don't think we even need a formal process change to do so: just an agreement from the IESG that they would not "step in the way" after the said body says it's done with a proposal (we even have a mechanism for this though it's not procedurally suited to modify BCPs: IAB Informational RFCs).

Note that I believe that if there would be a significant community agreement on any change, the IESG would not stand on the way no matter its members' personal beliefs. (Though getting that consensus might be easier if there was another, less loaded body evaluating and helping one to drive the efforts.)

---------- Forwarded message ----------
Date: Thu, 4 Aug 2005 09:42:24 +0300 (EEST)
From: Pekka Savola <pekkas@xxxxxxxxxx>
To: newtrk@xxxxxxxxxxxxxxxxx
Subject: On the priorities of process change

(This might have been appropriate to the IETF list but decided to go for a smaller scope this time.)

Bert and Sam's comments on the plenary made me think of the process change
priorities a bit.

I'm symphatetic to the belief that we must not work on too many things in
parallel; if we do, there is a danger that the community is not able to give
sufficient concentration to the process improvement effort.

In that light, I've gotten the feeling that either:
a) we must get to a resolution on SRD/ISD Very Soon Now (so that we can move on to focus on other things), or

b) it might be best to abandon (or put on a back burner) the SRD/ISD approaches, because AFAICS, in the grand scheme of things, I don't think they actually provide significant improvement on timeliness or quality.

(But rather, the approaches "just" improve the external representation of our work and make us more compliant with RFC2026. Maybe the decision to charter the WG was a bad one, years ago, or maybe it was an attempt to collect "low-hanging fruit" without realizing that we didn't know where the fruit was and low or high it was.)

It seems that we should be better focusing on the more pressing problems (which are out of scope of this WG):
 - improving the IESG management/leadership capabilities to better lead,
   steer, help, review, etc. [Harald's twolevel, John's standard review
   panel, etc. proposals]
 - improving the document workflow (up to 'Publication Requested').
   I doubt this requires process changes, rather than cultural changes or
   tools improvements.  However, I doubt this could get proper attention
   prior to the IESG's load on the day-to-day techincal job is decreased.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]