[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: diverging views on adding range constraints in MIB module revisions
.. snip a log of good stuff ..
> > And we should also try hard to make the review itself a friendly
> > act, making sure we try hard to explain things well, in an
> > atmosphere that is friendly and such.
>
> And indeed, I certainly agree with that.
>
I believe we all have those good intentions.
And I even try to keep an eye on it when I have someone else
do the review....
Maybe some of you should keep an eye on me when I do a review
myself (I do quite a few in fact). I know that once you dive
into it, it sometimes becomes more difficult to sit back and
look at it objectively. We can help each other.
> > Another issue are turn around times - which are sometimes not as
> > good as they should be.
>
> That is also true. The fault is not always that of the MIB reviewer,
> though. I've turned around reviews in as little as 48 hours when the
> MIB module was exceedingly well-written. A more recent case took me
> about two months to turn around because the authors were inexperienced
> and made many design mistakes that had to be corrected in order for
> the MIB module to be implementable. Reviewing that module and writing
> up the comments -- which at the authors' request included specific
> recommendations for changes -- took me quite a long time.
>
In general (there are always exceptions), I have been quite pleased
with turn-around when people promised to do a review by some date.
It then sometimes happens that the authors or WG take another 3-6
months (or sometimes even more) to come back with a revision.
Well, after such WG/author behaviour... one can expect the MIB
reviewer to be a bit less responsive. I in fact do tell WGs
and authors that too when I see it happen.
> > Perhaps we actually need to draft some text
> > about MIB reviewer ethics. I am serious.
>
I think that doing the guidelines and then trying to do reviews
accordingly is gonna be helping a lot in that respect.
Also this mreview list can help if we see issues/concerns that
we are not sure of.
> I'm aware that there are some authors that have not been happy with
> the process (cf. Andrew Smith's crack about "MIB quacks"), and
> maybe what you are suggesting could help. Although I won't volunteer
> to actually draft the text, I'll be happy to provide feedback if you
> wish to do so.
>
Don't worry to much if someone somtimes uses terms like "MIB quacks"
or other imflamatory email. I always try to put myself in their
shoes... and then often I can understand it somewhat. Not agree,
but understand... with that mindset I can most of the time get
along with them afterwards. And again, there are exceptions.
> One point that is worthwhile to note is that the reviewer's role is
> that of advisor to the responsible AD. The reviewer does not have
> final say; that's the AD's (and IESG's) job. In my view, my job as
> reviewer is to give the responsible AD the best advice that I can,
> and if I were to give the OK to broken stuff then I would be
> derelict in that duty.
>
When you do a MIB review at my request, then yes, you are serving
as advisor to me (which I appreciate very much).
Sometimes I ask people to be MIB advisor on a WG. In that case
you are advisor to the WG first, and interafce back to OPS ADs
and WG responsible AD.
Bert
> //cmh
>
>