chore: Update CONTRIBUTING with process and minor changes#255
Conversation
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Attributes
Other
Bug Fixes 🐛
Documentation 📚
Internal Changes 🔧Deps
Deps Dev
Other
Other
🤖 This preview updates automatically when you update the PR. |
|
Gonna put this to draft for now since things are moving fast and we'll prioritize getting conventions up to speed before we make the process stricter. |
| ## Policies | ||
|
|
||
| ## Attributes | ||
| ### Attributes |
There was a problem hiding this comment.
should we add naming rules & examples?
Naming rules:
- Use dots as separators, not underscores (
http.request.method, nothttp_request_method) - Namespace first (
db.system, notsystem.db) - Keep names stable! Renames require deprecation cycles across all SDKs that adopted the attribute!
There was a problem hiding this comment.
Done. I weakened the "Keep names stable" one to "Prefer keeping names stable". We did take the opportunity for span first to change some span names for frankly quite terrible, namespace-less predecessors (I'm guilty of this a lot 😅). I think this shouldn't be discouraged too much but I agree that we shouldn't rename attributs "for fun" or more realistically because a name doesn't sound perfect.
dingsdax
left a comment
There was a problem hiding this comment.
Do we want something about the generates typed constants in CONTRIBUTING.md? What's our plan there, do we encourage that?
529821e to
db3373a
Compare
For us internally, I think that's a good idea. I think everyone should be able to cut a release at any time. I added a paragraph how to cut a release and what version to choose. For users, I don't think this plays a role as we'd rather expose the attribute constants via our SDK packages (though internally, the SDK can depend on the generated packages). |
Uh oh!
There was an error while loading. Please reload this page.