Triage Process and Status Tracking

[slott56]

Triage Approaches

We have two mechanisms available for tracking status:

• GitHub via issues.
• The wip.toml via pull-requests, reviews, and approvals.

Clearly, we must update the wip.toml periodically as new test cases are added to the CEL-Spec repository.

1200 WIP tests seems a right bother to track on GitHub as issues.

My preference is to tackle these kinds of things off-line. (I don't have a great justification. i'm old and platforms come and go, so I like to keep things in the code and make our processes platform-agnostic.)

Off-line Approach

This seems to suggest that a unified wip.toml might not be ideal going forward. What we may want to think about is cluttering the WIP configuration loading into two tiers. One tier has a list of source files. The lower tier has the details.

Here's the upper-tier file.

# Top-level WIP status indicators.
[bindings_ext.bind]
    discussion = "https://github.com/cloud-custodian/cel-python/blob/main/tools/wip.toml"
    source = "bindings_ext/bind/bind_cases.toml"

[block_ext.basic]
    source = "block_ext/basic/basic_cases.toml"

The lower tier is a directory tree with a feature/section/section_cases.toml organization.
Each individual file will then have a respectably small number of cases.
Currently each TOML file is a mapping of case name to tag list.

Status?

• We could throw a few comments at the top of the file with status.
• We could add one or more _status = "I got this" line or _see = "issue #131" or such-like annotations to help clarify intent.

We can then address each features/section as separate PR's without endless merge conflicts stemming from a single file.