Add Engineering Ownership to Principles & Practices #5296
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for sourcegraph-handbook ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
quinnkeast
reviewed
Oct 17, 2022
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
…ctices.md Co-authored-by: Quinn Keast <qkeast@sourcegraph.com>
rafax
reviewed
Oct 17, 2022
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
|
I 100% agree with this, and honestly it's great to have this as a publicly documented principle 👍 💯 |
…ctices.md Co-authored-by: Rafał Gajdulewicz <rafax@users.noreply.github.com>
jhchabran
approved these changes
Oct 17, 2022
|
This stuff is gold, LGTM 🥇 |
eseliger
approved these changes
Oct 17, 2022
marekweb
approved these changes
Oct 17, 2022
sqs
reviewed
Oct 18, 2022
|
|
||
| Sometimes it means changing code that you don't officially own on paper – because you need the code to be changed in order to fix your customer's problem. You need team A to build FooWidget but team A is busy with something else and said they can't do it at the moment? Forget about the which-teams-owns-which-folder level of ownership and start asking: can _you_ build X? Can you build a prototype and get sign-off from team A and then continue, because your customer is waiting for it? You can expect your collaborators to be open towards contributions, so why not make use of that? | ||
|
|
||
| Sometimes it's about civil disobedience. That doesn't mean you should break the law or behave against our values. No, on the contrary. It means that sometimes a process or a convention has outlived its usefulness (or goes against our values) and the only way to demonstrate that is by not doing it, and calling it out even if no one asked you. Other times it means breaking the chain of command, if, for example, you think something's going to happen that will affect a customer in a negative way but you don't think anyone's listening. |
sqs
approved these changes
Oct 18, 2022
bobheadxi
approved these changes
Oct 18, 2022
pjlast
approved these changes
Oct 18, 2022
chrispine
approved these changes
Oct 18, 2022
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
content/departments/engineering/dev/process/principles-and-practices.md
Outdated
Show resolved
Hide resolved
…ctices.md Co-authored-by: Chris Pine <chrispine@sourcegraph.com>
efritz
approved these changes
Oct 19, 2022
steveyegge
approved these changes
Oct 20, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is based on the "Engineering Ownership" document I shared a few weeks ago.
Feedback on that document has been positive and encouraging, but quite a few of you asked: what's the next step? how can we make sure everybody in the company lives this? I do not know, but I do think that having it in the handbook is a great next step. So here we are.
Some of the Google Docs comments you all left I tried to incorporate, at least where I thought it was possible. There's still more comments in that doc that should be recorded somewhere (i.e. about how to do cross-team collaboration, or how to find out who owns what), but I don't think they fit into this document here (as part of "Principles & Practices").