distribution(goals): add monitoring developer experience #2184
Conversation
|
Notifying subscribers in CODENOTIFY files for diff 7a3f61c...274dc85.
|
| @@ -67,6 +67,16 @@ Creating a new release for our deployments is currently a semi-automated process | |||
| - Document project and folder usage guidelines. | |||
| - Set spending limits for dynamic environments. | |||
|
|
|||
| ### Improve Sourcegraph monitoring developer experience | |||
|
|
|||
| - **Owner**: Gonza, Robert | |||
There was a problem hiding this comment.
@pecigonzalo not sure who to add as owners here, saw that we generally seem to have 2 owners so I just added the two of us
There was a problem hiding this comment.
Its generally the one spearheading the project, I think it would make sense for it to be you and @davejrt as I can only sporadically work on project unfortunately.
| @@ -67,6 +67,16 @@ Creating a new release for our deployments is currently a semi-automated process | |||
| - Document project and folder usage guidelines. | |||
| - Set spending limits for dynamic environments. | |||
|
|
|||
| ### Improve Sourcegraph monitoring developer experience | |||
There was a problem hiding this comment.
This should be more tightly scoped. There isn't a clear end here. We could always improve the monitoring experience.
There was a problem hiding this comment.
This is the "monitoring development" experience, not the general monitoring experience. I see your point here, but I believe this should defined by the desired outcomes more than its title.
Still it could be possible you dont think the outcomes tighten that scope enough.
There was a problem hiding this comment.
I agree that both the title and the documented outcomes are not clear and scoped. A reader needs to be able to understand what done looks like. A problem statement is also missing.
|
@daxmc99 If we have this as focus, I believe we should have a goal attached to it. Maybe the goal is not explicitly about monitoring, but a part of that goal is achieving this. wdyt? Do you think there is a better way to track this or you dont think its worth adding any goal for it? |
I'm not sure this should be something distribution listed as a goal. Our monitoring pillars provide some good guidance on what we want our metrics to provide, and anyone can make use of those to make improvements. Improving developer experience sounds like something for an internal tools team? I think distribution should keep our goals tightly scoped to issues that impact customers. If our monitoring dev experience is resulting in developers not creating dashboards or we lack the observability to notice when a problem is occurring then we can address that. |
I agree this will likely slip in the future, but right now, like with other tools (Buildkite, CI in general, Monitoring generator, many testing/dev scripts, etc) we do own that "tooling" that allows other engineers to create dashboards/alerts for the different services.
I believe this is the case, but also that some of our customers other internal engineers. eg. The CI platform. |
|
@pecigonzalo should I close this? I agree with the sentiment here that there is no clear end to this, and more of a statement expressing "this is something we own and want to continuously improve", which is already expressed in ownership areas (well actually now that I look at it, it doesn't really express this) - I think we should have the flexibility to tackle a project spanning a few sprints (i.e. monitoring pillars redux) without being tied to a long-running goal (our goal should always be to improve the state of our ownership areas as well right?) |
|
Opened #2399 as an alternative! |
|
Let's close it. |
Adds an overarching goal of "improving monitoring developer experience", the first step of which is the monitoring pillars redux (which I've renamed to emphasize that it is more about reaching feature parity with our redefined monitoring pillars than fulfilling all the stretch functionalities that have been pitched to us / are tangential to some of the work here)
I'm not entirely sure if the wording here encompasses everything, and there's only one strict milestone right now as well (maybe more will come up later on after teams have had a chance to try out the work that will come from the first milestone?)