[Project Automation] Create High level tracker workflow + readme + helper script

[jarmak-nv]

This pull request introduces a new GitHub Actions workflow for high-level project tracking and provides supporting documentation and scripts. The main changes include the addition of the workflow configuration, a detailed README explaining the workflow, and a helper script to obtain necessary project and field IDs.

New GitHub Actions Workflow:

• .github/workflows/project-high-level-tracker.yaml: Adds a comprehensive workflow to automate the management of GitHub Projects, including steps to process branch names, determine development stages, and update project fields based on release schedules.

Documentation:

• docs/project-automation-readme.md: Provides an overview of the new workflow, its architecture, and configuration details. It includes a mermaid diagram to illustrate the workflow and instructions on how to obtain necessary project and field IDs.

Helper Script:

• docs/project-graphql-helper.py: Adds a script to fetch project and field IDs from the GitHub GraphQL API, which are required for configuring the workflow.

[jameslamb]

I took a first pass at this, will do a more thorough review next week. Just publishing a non-blocking review now so you can see my first few comments.

[jameslamb]

General comment for all of these default: values with what look like identifiers from a service.... what are they? Where did the values come from? Are they intended to be overridden?

If every user of this is expected to provide these values at the site where this is called, then I think that:

• the defaults should be removed
• the inputs should all have required: true
• docs should be added here explaining how to set values for them (either how to find the things to hard-code, or how to get these via templating with the various runtime contexts GitHub Actions provides: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context)

If these values are intended to be used literally and never overridden, then I think that:

• they should be moved out of inputs and instead either hard-coded below or shared via the env. context (https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#env-context)

If these values could be used literally but might be overridden, then I think that:

• the inputs should all have required: true
• docs should be added here explaining how to set values for them
• code comments should be added explaining where these defaults came from

[jameslamb]

I'm a little confused by the naming with *_ID for these things... they look like names or labels. I think changing the input names to something like *_NAME would make it clearer that these are free-text display names that don't have uniqueness constraints.

Am I right about that? If so, would you consider that naming change?

[jameslamb]

I don't understand these workflows and the GraphQL code very well, so apologies if this is an ignorant question... does any of this automation assume that 1 issue will be resolved by exactly 1 PR?

The language here (talking about "the" PR) makes me think that it might.

I think that's an assumption that's likely to be violated often, especially for large efforts like rapidsai/cuvs#735