-
Notifications
You must be signed in to change notification settings - Fork 241
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
Proposal to create a SIG for Real User Monitoring #830
Comments
Yes please! |
Yes, please include me. |
1 similar comment
Yes, please include me. |
yes, yes. I am interested. |
+1 |
I would like to propose meeting on Wednesdays 8am Pacific Time, which would work for European time zones. Please thumbs up if that works for you, or propose a different time. |
8.30am PT is preferable for me (after the school drop off)
…On Tue, Sep 14, 2021 at 5:00 PM Martin Kuba ***@***.***> wrote:
I would like to propose meeting on *Wednesdays 8am Pacific Time*, which
would work for European time zones. Please thumbs up if that works for you,
or propose a different time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#830 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVMH2EO7H7ZGQXP2GQJXJ3UB7O2DANCNFSM5DTNR2WQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
If the meeting is scheduled for longer than 1hr, 8:30am Wednesday would conflict with the JS SIG, that starts at 9am (not sure how many people are interested in both) |
I would think that the overlap would be quite high, given the need for browser-based RUM. |
1/2 hour weekly might be good enough, but a few other options I can think of
|
Conflicting with Java & Swift seems very problematic...given iOS and Android. ;) |
Very interested in joining. 8 / 8.30 am PT on Wednesdays for 30 minutes would be great (already added 👍 for both comments). |
Interested in joining 8 or 830 AM PT on Wed would match my European calendar |
Let's go with 8:30 on Wednesdays for 1/2 hour to start with. If we consistently need more time, then we can revisit. |
Sounds good to me.
…On Thu, Sep 16, 2021 at 10:03 AM Martin Kuba ***@***.***> wrote:
Let's go with 8:30 on Wednesdays for 1/2 hour to start with. If we
consistently need more time, then we can revisit.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#830 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVMH2AICLRRTG7F6RCFWEDUCIPOPANCNFSM5DTNR2WQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
@tedsuo Would you be able to help us with putting this on the calendar? |
Creating this now |
Crap, we already have three meetings during that period and we only have three Zoom accounts. I'll contact the CNCF to make another account. For now I'm going to set the meeting to start at 9:00 so that it doesn't overlap. |
Done. We can adjust the time to 8:30 once we get more Zoom accounts. |
I am interested in joining too. Please include me. Thanks. |
The meetings will be fully public, so feel free to join in! All are welcome. |
there are four accounts. Please check the document |
Nice! I'll update this then. I've reduced my ask on #824 to only request one additional account. |
Hey folks -- can someone add this to the SIG table in the README? |
Created #879 to add this to the list |
Hello! I would like to propose that a new SIG is created for Real User Monitoring use cases.
The goal of this group, I think, should be standardizing how RUM data is represented, so that RUM instrumentation is portable across different backends/vendors.
Example use cases
There is a recent OTEP proposal that attempts to address these use cases by introducing a new signal in the OpenTelemetry data model. Based on the comments on this proposal, there seems to be a number of different opinions on how it should be tackled.
There is also an existing Slack channel for client-side telemetry where some of this has also been discussed.
The immediate focus of this group would be
If anyone else is interested, please comment.
The text was updated successfully, but these errors were encountered: