feat: surface RPC requests for AD decisions at datatracker - #11596
Conversation
The RPC tool sends the action holders it is waiting on with every publication queue push, and the datatracker discards them. Add somewhere to keep them so an Area Director can be shown when the RPC needs a decision from them. The RPC tool owns these entries; this is a read-only capture held here so the datatracker can query them efficiently. Only open entries are kept, so readers do not need to filter. The admin registration is read-only for the same reason: every push replaces the contents.
The publication queue push already carries the action holders the RPC is waiting on. Reconcile them against the open entry table on each push, which is a full snapshot: entries the RPC completed or removed, and entries for documents that have left the queue, are dropped. Never associate an entry with the "(System)" person. The RPC tool sends its own placeholder person when no real one was named, and that arrives both with and without a body set - its edit path can change the body without touching the person - so the person id alone has to be enough to reject it.
Add a section to the AD document list for the actions the RPC is waiting on that AD for. Each row links to the queue site final review page for its document, which is where the request is spelled out - unless the RPC has not assigned an RFC number yet, in which case there is no such page. Who holds an action and since when is public. The request text itself is shown only to the IESG, the Secretariat, the RPC, and whoever is being asked for the decision.
Add a table listing each AD the RPC is currently waiting on, above the state count tables and linking to that AD's document list. Only ADs with something pending get a row, and the table is absent when the RPC is waiting on nobody. It is kept out of the state count tables because it cannot honestly join them: those show a 120-day trend, while the open entries the RPC pushes are a snapshot with no history to bucket.
Add the people the RPC is waiting on to the RFC Editor block, so the document itself says who holds the decision and since when. Only entries naming a person are listed. An action held by a body, or by the RPC tool's own placeholder person, is already covered by the queue status line in the same block.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #11596 +/- ##
==========================================
+ Coverage 88.59% 88.71% +0.12%
==========================================
Files 333 335 +2
Lines 44728 45256 +528
==========================================
+ Hits 39626 40151 +525
- Misses 5102 5105 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| # datatracker id - so an action holder must never be associated with this pk. | ||
| # Which pk the RPC tool uses is configurable at its end, hence the separate | ||
| # check against the "(System)" person the datatracker actually has. | ||
| SYSTEM_PERSON_ID = 1 |
There was a problem hiding this comment.
yuck. I think this is already captured somewhere more global
There was a problem hiding this comment.
No it isn't - the constant is scattered around the code. Cleanup for a separate task (see #11607)
jennifer-richards
left a comment
jennifer-richards
left a comment
There was a problem hiding this comment.
Comment and a few nits
| if person == system_person or person.pk == SYSTEM_PERSON_ID: | ||
| return None |
There was a problem hiding this comment.
Redundant with l412-413
| <h2 class="mt-5" id="rpc-pending">RPC decisions pending</h2> | ||
| <p class="text-body-secondary"> | ||
| Documents in the RFC Editor queue for which the RPC is currently waiting on a | ||
| decision from an Area Director. Current state, not a {{ delta }}-day trend. |
There was a problem hiding this comment.
The "Current state, not a ..." comment seems unnecessary
There was a problem hiding this comment.
It's there to answer "Why aren't you graphing this"
There was a problem hiding this comment.
It seemed evident to me from the description / existence as just a number, but I'm not the audience so fine either way.
| asked for the decision. This gates the document page only - the AD document | ||
| list shows the request to everyone. It is a display choice rather than a | ||
| confidentiality boundary: the queue site publishes the same text on its | ||
| public final-review pages. |
There was a problem hiding this comment.
Also available via api/v1 and from a dev database snapshot (don't need to add this comment, just pointing it out)
Framing it as a can_ method, which we've mostly used as a permission control for actions, is a possible source of confusion. The docstring is probably adequate to clarify though.
| {% if entry.final_review_url %} | ||
| <a href="{{ entry.final_review_url }}">Final review</a> | ||
| {% else %} | ||
| <span class="text-body-secondary">(No RFC number yet)</span> |
There was a problem hiding this comment.
Switching the label between "Final review" and "(No RFC number yet)" is a peculiar toggle
There was a problem hiding this comment.
Claude doesn't understand yet (and neither the dt nor purple code enforce) that there won't be action holders until the doc is in final review, and it's built a few gate places around that happening. Still, it's a confusing artifact, and I'll remove it.
2 participants
Fixes #6409
Add a section to /doc/ad/{ad.name} for the actions the RPC is waiting
on that AD for. Each row links to the queue site final review page for
its document.
Add a table to /doc/ad/ listing each AD the RPC is currently waiting on,
above the state count tables and linking to that AD's document list.
Only ADs with something pending get a row, and the table is absent
when the RPC is waiting on nobody.
Add the people the RPC is waiting on to the RFC Editor block of the
document's main page, so the document itself says who holds the
decision and since when.