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

[non-normative] Answer commonly asked judgement questions for defining Specification #4293

Open
jsuereth opened this issue Nov 13, 2024 · 0 comments
Assignees
Labels
spec:miscellaneous For issues that don't match any other spec label triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned

Comments

@jsuereth
Copy link
Contributor

From @jack-berg's Comment on #4286, we should address the following:

  • Should we extend an interface, even when its allowed? Extending interfaces is easier in some languages than others. Ideally we get it right the first time (and we should strive for this), but in the event we don't, when does the value of extending an interface trump the friction it causes in the languages where they are hard to extend? This is related the "be stable" value, but not entirely captured.
  • Language implementation or collector. We often have proposals for use cases that could be done in the collector, but could also be done in the SDK which is advantageous to some users who don't want to use the collector (or in some cases can't). Given that spec API / SDK features need to implemented 11 times, when is it appropriate to reject a API / SDK feature proposal that can be accomplished in the collector? Doing so can help us focus on more pressing problems, and potentially simplify user story by reducing the number of ways to accomplish the same thing.
  • Plugin extension point or structured config. There’s a trade off between SDK plugin extension points (i.e. exporters, processors, samplers), and a more limited or structured approach (i.e. exemplar filters, attribute limits). SDK plugin extension points offer more flexibility but generally have more cumbersome and less standardized configuration. Reducing flexibility (or adding guardrails) can add safety and improve UX in certain domains. When do we choose one or the other? This is related to the "be simple".
@jsuereth jsuereth added spec:miscellaneous For issues that don't match any other spec label triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned labels Nov 13, 2024
@jsuereth jsuereth self-assigned this Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:miscellaneous For issues that don't match any other spec label triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned
Projects
Status: No status
Development

No branches or pull requests

1 participant