Re: [Gendispatch] How I spend my time as an AD

[Warren Kumari <[e-mail]>]

On Tue, Sep 19, 2023 at 1:01 PM, Martin Duke <[e-mail]>
wrote:

> Some people in the community are interested in how ADs spend their time.
> Here is a data point.
>

… and here is some data from me:
https://docs.google.com/spreadsheets/d/15vSsL_aD2sMb_SFXmvlXwf781xZ4SfLqT-Mf5YavKqI/edit?usp=sharing

Note: I only did this for 2 days, shortly after a meeting - this means that
it isn't hugely representative of an "average" week, but it hopefully at
least give a flavor. One thing that I discovered while collecting this data
is just how much overhead it involved (which is why it is only 2 days :-)).
I'm somewhat ADHD, and the context switching of "Do something, record
something, do something, record something" was crushing. It was also very
unclear how I would count almost all of the items.

As an example, after aggressive filtering I get ~250 emails per day - these
are spread across email lists which I'm on because I'm an AD, email lists
which I'd read anyway, ICANN mail, corporate mail, etc. If I read an email
about a draft in DNSOP, is that AD time? Or is general IETF time? I'd
probably read it even if I wasn't DNSOP AD, but I'd also likely pay less
attention to some of the less interesting replies…

Yesterday I mentioned an OpsAWG draft on the NANOG list -
https://mailman.nanog.org/pipermail/nanog/2023-September/223301.html . Do I
count that as AD / IESG time? I'll end up progressing the document, but I
also happen to believe that this draft is really useful, and I would have
reported on it either way, so perhaps it's just general IETF time?

On a personal note, I am fairly disappointed (and somewhat hurt) that
instead of just *asking* how I spend my time, a BoF was proposed. To me at
least, this felt like "Not only are you doing this wrong, but it is so
wrong that your input is not useful or needed. We'll design a timecard for
you to fill in, and make sure your TPS report is on my desk by Friday."

W




I am not including the time I spend as a normal IETF participant: writing
> drafts, participating in WGs I would attend anyway, and attending IETF
> plenary meetings.
>
> These percentages are a rough fraction of a 40-hour workweek, averaged
> over the year. I did a time card for my own information three years ago,
> long since lost, but this is an estimate based on a little reflection on
> the tasks I perform.
>
> 8% - Meetings: Telechats, a weekly sync with my co-AD, occasional one-offs
> for IEEE syncs, BOF reviews, etc
>
> 2% - WG management - finding chairs, occasional 1-on-1s, chartering,
> errata, BoFs, monitoring mailing lists, etc. Personally, I tend not to wade
> into WG document threads very much, to keep my perspective clear for the AD
> review. Others may differ. There was a period I spent about 5% of my time
> clearing the errata backlog, but that is long past.
>
> In transport, we do not get many BoFs. I have also been fortunate in
> having great WG chairs that can handle most problems, so thank you to them.
>
> 3% - AD [document] Evaluation -- With only 5 WGs, I do not have many of
> these. I take these really seriously and a review usually takes the better
> part of a day, sometimes more. Other ADs almost certainly spend more time
> because they have many more documents.
>
> 3% - Standards process management: actively participating in policy work
> -- IESG statements and such -- is essentially optional. I have gotten
> interested in certain initiatives. It is certainly possible to spend more
> or less time on this.
>
> 2% - Retreats. These meetings essentially take a full week, but are
> happening only once per year. You could put this in the "standards process
> management" bin if you like.
>
> 10% - IESG review - Until about a year ago, this consumed substantially
> more time for me, as much as 40-50%. For multiple reasons, I've trimmed
> this down to focus on documents with transport implications (which is not
> many of them). In the context of any particular review, I've reduced my
> focus to major problems and any transport issues. For what it's worth, I
> don't think this scaling back has meaningfully reduced my impact on the
> IETF.
>
> For most ADs, a much larger percentage of ballots have issues pertaining
> to their area of expertise. If I applied the same criteria to being SEC AD,
> I would probably be spending *at least* 40% of my time on balloting.
>
> *******
>
> In summary, I'm spending about 25%-30% of my workweek on AD-specific
> stuff. When I started, it was over 50%. mostly because I was much more
> thorough on IESG ballots. An additional chunk of time is spent on being an
> IETF participant. Although I participate in more policy work than the bare
> minimum, I would say that this level of commitment is pretty close to a
> lower bound for competent* execution of the duties because:
>
> - Transport is small: few WGs, not that many documents, largely irrelevant
> to most IESG ballots
>
> - I am experienced: I've formed an opinion about what matters and have
> stopped doing stuff that I don't think matters.
>
> ********
>
> Some closing thoughts:
>
> No one asked me, but I don't think eliminating AD tasks that take <5% of
> the week is going to make a difference in recruiting: it's still a matter
> of asking your manager to be removed from some dayjob tasks. The real money
> is in (1) eliminating lots of working groups; (2) having way more ADs;
> and/or (3) fundamentally changing the nature of IESG balloting. All of
> these have significant drawbacks.
>
> I will also note that we historically have plenty of AD candidates for
> some areas (SEC and RTG) and almost none in others (TSV). It is apparent to
> me that this is not just about workload and there are other factors at
> play, and the community would benefit from exploring these before taking a
> sledgehammer to the generic AD job description.
>
> WG management and AD Evaluation are the most important things I do and
> should not be abridged.
>
> If there's one place I regret not spending more time, it's adoption calls
> in my WGs. There are several instances where I have AD evaluated a document
> that isn't highly objectionable, but that I don't think is a particularly
> useful addition to the RFC series.
>
> Martin Duke
> Transport AD 2020-2024
>
> * I have received private feedback that my contribution has been
> reasonably competent, but others are free to disagree,
>