2019 Q1 Dev Backend OKRs

I think Distribution should shoot for completing enough of our GitLab Operator for Kubernetes (charts&19) to have it enabled by default in the charts. (Allowing no-downtime rolling upgrades)

As well as keeping our current Q4 OKR (gitlab-org/distribution/team-tasks#194 (closed)) as we have merged a proof of concept, but not yet reached the coverage of dependencies that would result in us closing the task.

There may be something different that @marin proposes next week, but we can start with these.

For Geo, we need to help the Production team with whatever they need to get Geo running for DR.

Selective sync needs to be enhanced to work at scale. Epic: gitlab-org&576
We would also reduce manual steps for the Production team if we could support GitLab Pages: gitlab-org&589

Those two seem reasonable for Q1, but open to discussion on them of course.

Initial thoughts:

Measure and increase our test coverage for the customers app (+x%)
Increase throughput by x%
Add a CE/EE backend maintainer in our team
Something involving security (security Issues are going to be a big focus in Q1, but i'm struggling to think of the correct metric at the moment)

I will update these throughout the day, after receiving feedback from the team.

Initial ideas:

Have team deliver N Create Deep Dives to increase set of people comfortable working on various parts of the Create feature set
- Inspired by @lmcandrew's "Manage 201" OKR in Q4
Port gitlab-shell to Golang
- See gitlab-org/gitlab-shell#74 (closed) for background
- Not sure if this is appropriate for an OKR there to be a significant amount of variation week to week and month to month over the first 3 months we try this approach anyway
Add one more CE/EE backend maintainer
Add a database maintainer (cc @abrandl)
- See https://gitlab.com/gitlab-org/gitlab-ce/issues/52210 for context

Something involving security

@lmcandrew What about an SLA like time to pick up or time to resolve? Then the metric could be x% of security issues need to be addressed within the SLA? (Just a thought)

@lmcandrew What about an SLA like time to pick up or time to resolve? Then the metric could be x% of security issues need to be addressed within the SLA? (Just a thought)

Thanks for the input! The problem is we already have the Security SLAs and the concern in the team at the moment is that we will break this for serveral ~P3/~S3 Issues (you can see the number we have here). The Security team are aware of this and we are working with them to make sure we are prioritizing appropriately for each milestone.

Given this, it feels like this is actually more of a prioritization concern (therefore more relevant to Product/Security). Perhaps from an engineering point-of-view we should be more interested in decreasing new Issues that are being created and measuring this, and increasing throughput so we can generally ship more Issues.

I also appreciate this isn't a concern unique to the Manage team!

We will have more Elasticsearch work. We haven't made much progress on this quarter's OKR (gitlab-org&429 (closed)) - despite a reasonable amount of effort - and I actually think we should tackle gitlab-org&428 (closed) first instead. However, that has product implications too, so I'd need to discuss it with @victorwu.
Something I would like for the team in general (including me) is more external output: blog posts in particular, but video demos or talks would also be fine too. For instance, for Plan we could have blog posts about Rails 5, CommonMark, JIRA, Elasticsearch, etc. These overlap a little with Deep Dives but would be more externally-focused.
I don't have a third right now

If throughput is in the director's OKRs (as in !17503 (merged)), it's not clear to me where that falls at the team level. (To me, changes in throughput by X% seem like they fail the https://about.gitlab.com/company/okrs/#okrs-are-what-is-different test.)

Perhaps from an engineering point-of-view we should be more interested in decreasing new Issues that are being created and measuring this, and increasing throughput so we can generally ship more Issues.

Yeah, I think that is the interesting part about security issues, and is critical for the long term anyway. We do record the versions affected when working on a security issue, so we would (I think?) be aiming to have the age of the average security issue increase - because that would indicate we are mostly fixing old issues, not introducing new ones?

https://about.gitlab.com/company/okrs/#format says:

Format

1. Owner: Objective as a sentence. Key result, key result, key result. => Outcome, outcome, outcome.

The => Outcome, outcome, outcome. part is only added after the quarter started.

Each owner has a maximum of 3 objectives.

Each objective has between 1 and 3 key results, if you have less you list less.

So we don't actually need three items each. I think the objective for a bunch of the suggestions above (deep dives, blog posts, even maintainership) is knowledge sharing, and that would roll up nicely.

(This is premature, because the goal according to #3538 (comment 125997953) is that we will try to make these line up better in the next iteration. I just find it interesting!)

Have team deliver N Create Deep Dives to increase set of people comfortable working on various parts of the Create feature set.

When I set this for Q4, @tommy.morgan mentioned he preferred lagging metrics instead of leading metrics (that is, setting the target result, rather than defining the actions to get there). The target result for me was to increase knowledge sharing - but this feels really difficult to measure. (to futher explain lagging vs leading in this context: if we complete all of the Deep Dive sessions, but no one watches, then we haven't actually achieved the target result).

Having said this, I did actually find it useful to have as an OKR as it added increased importance and visiblity on the value of the sessions. Although we won't meet the target we set, I think collaboration & knowledge sharing within the team has improved and other teams have been really complimentary about the value of the sessions.

Another result for knowledge sharing could be 'have $n people ship MRs related to $feature'? That will only work if that lines up with product priorities, of course, but say that hypothetically only one person knows how SAML works, then one way of demonstrating that we've started to resolve that is to have two other people ship SAML changes.

@MadLittleMods I forgot to tag you in on this - please let me know ASAP if you have any thoughts on Q1 OKRs for Gitter. One that I could suggest based on the discussion yesterday would be getting Gitter set up to follow the standard security release process.

If throughput is in the director's OKRs (as in !17503 (merged)), it's not clear to me where that falls at the team level. (To me, changes in throughput by X% seem like they fail the https://about.gitlab.com/company/okrs/#okrs-are-what-is-different test.)

I think changes in throughput by X% are different because it's not "part of your day job" to aggressively improve throughput. At least not right now, since we just started measuring it, and not forever, because we can't achieve infinite throughput. But for now I think it makes a good OKR.

Because it's already at the Development (i.e. Senior Director) level already, though, I don't think it makes much sense to do it at a team level also. Maybe there are goals we could set around improving the weekly consistency of throughput (that is, making the release less "lumpy")?

Because it's already at the Development (i.e. Senior Director) level already, though, I don't think it makes much sense to do it at a team level also

I think that depends on the answer to #3538 (comment 125976122)? We don't have that answer right now, because it isn't particularly important, but that was the impression I got from that conversation.

Eric answered that:

no different from previous quarters in that regard. Just propose whatever you and your managers want to do, and indent them accordingly. We can align in the next iteration.

So let's treat them as independent for now.

@DouweM

Transition from limiting the issues in a milestone and issues assigned to engineers by their weight, to everyone simply working from the top of a prioritized list, without giving up predictability

I think it's still very important for us to be scheduling out the full release for each engineer on the team. Is there a way we can rephrase this?

Via #g_manage on slack:

Something involving security (security Issues are going to be a big focus in Q1, but I'm struggling to think of the correct metric at the moment)

Maybe something like:

Objective: Proactively reduce future security flaws. KR1: Identify five areas where we have systematic/pervasive/repeated security flaws, KR2: Finalize plan to tackle three areas, KR3: Two merge requests merged

When I set this for Q4, @tommy.morgan mentioned he preferred lagging metrics instead of leading metrics (that is, setting the target result, rather than defining the actions to get there). The target result for me was to increase knowledge sharing - but this feels really difficult to measure

For lagging metrics could we have a softer metric such as an internal survey?

E.g. Objective: Broader understanding of our areas of expertise. KR1: When surveyed, X% of the team could comforably contribute to areas other team members work on. KR2: 10 MR reviews conducted cross-team in areas requiring deep understanding. KR3: 6 resouces produced to share that knowledge with future team members (such as documentation, presentations, or blog posts).

The surveyed KR could then relate more to the desired result, with others being more prescriptive about how we get there.

For my part I'm thinking about a couple along these lines:

Improve documentation and training for supporting our customers - I know Distribution has been getting pulled in a lot for assistance on things like kubernetes setup, and while I haven't heard specifically regarding other teams I bet with new functionality like SmartCard going out we probably have better room to collaborate with customer support and/or professional services to help smooth their path when it comes to helping out our customers. So I'd like to meet with them and identify the top hotspots and work with you all to get some merge requests out.
I also want to do something on getting some of our issue boards needs (for the prioritized list from product) prioritized, but am not 100% sure on how to frame that just yet. I'll figure something out though.

For Gitaly, I'm thinking we could potentially set an aggressive goal to have a beta for HA available by end of quarter. This may be too aggressive, but it's the biggest thing we seem to be hearing from customers right now so I think it would be a good OKR and I'd like to at least set in the draft. @jacobvosmaer-gitlab @zj @jramsay feel free to make other suggestions if you disagree :)

I'm going to be driving to Knoxville this morning/early afternoon but will plan to write up the first draft based on your feedback and get it merged later today. If I don't have input from you yet (@stanhu and @MadLittleMods so far) I'll leave it as a WIP but we really need to get some thoughts down on paper soon-ish. Thanks everyone.

@tommy.morgan For Gitter OKRs,

Use dev.gitlab.org for security issues
- This includes setting up new runners registered to dev.gitlab.org, https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/4599

The standard GitLab security process doesn't exactly fit how we can deploy Gitter and only need to worry about one instance,

@tommy.morgan For my OKRs, some ideas for discussion:

Reduce memory consumption of GitLab
1. Address 2 main consumers in gitaly-ruby: gitlab-org/gitaly#1298 (closed)
2. Reduce ProjectExportWorker usage by 50%: https://gitlab.com/gitlab-org/gitlab-ce/issues/35389
Make multithreaded server ready for production
1. Instrument with Prometheus metrics
2. Prepare production readiness review
Help solve critical customer issues (e.g. NFS-related bug from Q4)
1. Solve 1 P1 issue

mentioned in merge request !17541 (merged)

Something I would like for the team in general (including me) is more external output: blog posts in particular, but video demos or talks would also be fine too. For instance, for Plan we could have blog posts about Rails 5, CommonMark, JIRA, Elasticsearch, etc. These overlap a little with Deep Dives but would be more externally-focused.

@smcgivern and others: Have engineering folks considered posting on other popular platforms? I know our default is the GitLab blog. But we do have https://medium.com/@gitlab. (I don’t know when we are supposed to post on one vs the other.) And I am thinking of examples like this: https://medium.com/airbnb-engineering

Have engineering folks considered posting on other popular platforms?

@victorwu There is this addition to the handbook: https://about.gitlab.com/handbook/marketing/blog/#publishing-natively-on-linkedin-and-medium.

I personally like the GitLab blog because we use GitLab CI and Markdown. We have an engineering category in https://about.gitlab.com/blog/categories/engineering/ that should get more content.

I agree "beta Gitaly HA" is our next priority after "Git object deduplication GA". How far we will get with all that by the end of Q1 I don't know.

unassigned @stanhu

changed due date to December 31, 2018

assigned to @marin and @stanhu

Please make sure to review !17541 (merged) - we'll need final OKRs in by the end of the month, so I've adjusted the due date for this issue accordingly.

mentioned in merge request !17639 (merged)

mentioned in merge request !17641 (merged)

@tommy.morgan can we close this now?

closed

2019 Q1 Dev Backend OKRs

Designs

Child items ...

Activity

Format