Trask Stalnaker

> blocking temporarily to discuss whether we can unify screen coordinate representation with #2070 See #2145

> /cc [@trask](https://github.com/trask) - I recall you mentioned that something similar came up in Java, wonder if you have any thoughts on generic conventions/instrumentation for capturing function params and return...

Closing as there does not appear to be engagement from the necessary folks in order to move this forward at this time.

hi @RouxAntoine! can you expand on the motivation, e.g. I'm curious if this is for integrating with an ECS-based system (Elastic Common Schema)?

oh, this looks really interesting there are potentially lots of automations that could benefit from this which we haven't been able to implement due to the security issues around `pull_request_target`...

cc @open-telemetry/sig-project-infra-approvers

just as an fyi, it asks for these permissions (which makes sense): 

Interestingly the docs folks are implementing something similar manually, see pros/cons here: https://github.com/open-telemetry/opentelemetry.io/pull/6894/files#r2091256900

I was (finally) able to get something like this working without relying on an external github app: - [auto-spotless.yml](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/.github/workflows/auto-spotless.yml) - [auto-update-pull-request.yml](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/.github/workflows/auto-update-pull-request.yml) It's definitely not as simple as using autofix.ci, but...

annoyingly, CodeQL flags this approach ([auto-update-pull-request.yml](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/.github/workflows/auto-update-pull-request.yml)) as a "Dangerous Workflow" I'm pretty sure it's very careful to not be dangerous, but I also don't love marking the CodeQL warning as...