Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a RFC throughput metric to the Area Director Workload page #4579

Open
1 task done
Tracked by #40
rdanyliw opened this issue Oct 13, 2022 · 2 comments
Open
1 task done
Tracked by #40

Add a RFC throughput metric to the Area Director Workload page #4579

rdanyliw opened this issue Oct 13, 2022 · 2 comments

Comments

@rdanyliw
Copy link
Collaborator

rdanyliw commented Oct 13, 2022

Description

The RFC State Counts table of the AD Dashboard (https://datatracker.ietf.org/doc/ad) currently lists the number of RFCs associated with an add. To provide a sense of velocity in this process recommend adding an additional column as follows:

OLD RFC State Counts

  • Column 1 = AD Name
  • Column 2 = RFC Ed Queue
  • Column 3 = RFC

OLD RFC State Counts

  • Column 1 = AD Name
  • Column 2 = RFC Ed Queue
  • Column 3 = RFC
  • Column 4 = RFC/year = divide the number of RFC (per Col 3) by the years an AD has served (fractions ok)

Code of Conduct

@rdanyliw rdanyliw added the enhancement New feature or request label Oct 13, 2022
@rjsparks
Copy link
Member

rjsparks commented Oct 13, 2022

(Edit: the first question I originally asked doesn't make sense - I removed it).

Note that this comes with gritty bits - some people serve non-consecutive AD terms, so calculating "years the AD has served" isn't the most straightforward, especially if the gap is large and the history about past roles gets less clean. Or are you only wanting to include whatever the current contiguous set of terms are for the person?

This will produce oddly large numbers once an new AD starts handling documents but I guess that will just be entertainment...

@rdanyliw
Copy link
Collaborator Author

Computing this would definitely take some state information. I was thinking of computing this against total time serving as any kind of AD (and was assuming that this RFC count is bound to IESG time not IRTF).

We can only hope to be inspired by the seeming high velocity of document processing these new ADs would have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants