profile
viewpoint
Christina Forney christinaforney Sourcegraph Woodside, CA christinaforney.com

lsif/lsif.github.io 3

https://lsif.dev

rubyforgood/panda_app 2

Ruby for Good 2016: A tool to help researchers score observations of animal behaviors

christinaforney/Documentation 0

Documentation repository

christinaforney/gradle-wrapper 0

stock gradle wrapper

christinaforney/minimal-mistakes 0

:triangular_ruler: A flexible two-column Jekyll theme perfect for building personal sites, blogs, and portfolios.

christinaforney/my_jekyll_site_example 0

Example setup and steps for configuring Jekyll with Minimal Mistakes and Circle CI

issue openedsourcegraph/sourcegraph

Improve sign in/out UX

The sign in page should align with the new design consistency work we've been doing around headers and information architecture. There are some confusing moments with the different sign in options, and the UI could be significantly improved.

Additionally there are a few known issues:

  • And the sign in page's nav bar: https://github.com/sourcegraph/sourcegraph/issues/12547
  • The sign out page only has a dark theme: https://github.com/sourcegraph/sourcegraph/issues/9810
  • Once you sign out, the user flow makes it difficult to sign back in.

Each instance will have different options for signing in depending on what is configured by the Sourcegraph admin. Additionally, Sourcegraph Cloud offers running searches without authentication, but this is not an option for Server deployments.

created time in 11 hours

delete branch sourcegraph/about

delete branch : Add-items-to-the-Product-onboarding

delete time in 5 days

push eventsourcegraph/about

AlicjaSuska

commit sha da184f55c8bd8390a42e3b14afac5a05af369548

Add items to the Product onboarding (#1281)

view details

push time in 5 days

PR merged sourcegraph/about

Reviewers
Add items to the Product onboarding handbook

Based on my recent onboarding experience, I've added a couple of activities that helped me and could be useful for all new Product Team members 🎉

+4 -0

0 comment

1 changed file

AlicjaSuska

pr closed time in 5 days

push eventsourcegraph/about

Beyang Liu

commit sha cab0335955bada9ed5f2663a6c2e8f9278f08fb9

podcast: publish dan bentley

view details

Quinn Slack

commit sha 7f32717748ddc0961fad0d35a1a3d639e08b4310

add informal description of Big Code (#1283)

view details

Christina Forney

commit sha 6969375756c180fd25a66bd8a23fac4f87be699f

Product team goals (#1262)

view details

Quinn Slack

commit sha 14101c005cbdb3cd3bd9d6bf89e2b6ff0b5b0154

good goal

view details

Beyang Liu

commit sha cf334741b6add4903eeb699a47e6d461eb503553

Revert "Add new onboarding process for web teammates (#1259)" This reverts commit b8f71b9579c73a7edd3def5fa2ac61e2dcd26d44.

view details

Loïc Guychard

commit sha 6cda34f24061ad138ccf4385f5532676ef938253

Revert "Revert "Add new onboarding process for web teammates (#1259)"" This reverts commit cf334741b6add4903eeb699a47e6d461eb503553.

view details

Dax McDonald

commit sha c9b04c134bb18fa83589d702e0ab2e62729f4e51

Update release issue template (#1254) * Update release issue template Updates to make the release more straightforward for future releases * Update release tracking issue to ask product Going forward the release captain should be requesting blog posts updates from the product team

view details

Stephen Gutekanst

commit sha 6741ecdb90f045575169b5e35824f88cd3355ed0

distribution: architecture, security, cost estimation, creation, operations, and more (#1284) Open-sourcing our docs for managed instances

view details

Nick Snyder

commit sha 0c3aa62c17dda7b47dd9f3d9f767530de52e2c3d

Run build on every commit to master (#1286)

view details

Nick Snyder

commit sha 32aa286d0d6e596f5e34e1f2370cd78c0ab34e0b

fix link

view details

Loïc Guychard

commit sha 9e103d22c681b3876e0bf8450c35e33687b7b02b

Update web team handbook page (#1287) - Remove duplicate link to onboarding process - Reflect that TJ has joined the team - Reflect that Simon is no longer part of the team

view details

Felix Becker

commit sha 2fdb108a23c0e894b851f1257faf738761e36c12

Add @felixfbecker to team locations map

view details

Felix Becker

commit sha 2d1947b55a2d26bb94af1d23933ecf94dafb8bb8

Remove Tommy Roberts from team locations map

view details

Chayim

commit sha 9c2b20a21460ca44d2a4ea0cfb325bc487f42a48

Update index.md

view details

Bunny

commit sha 42b50163da72f913fc07d8f6a1ba917153713144

Fixes in line with handbook (#1288) * Fixes in line with handbook * Removed hyphen

view details

Beyang Liu

commit sha db443fca29035244b0c4a3a43bbad446562f7c72

podcast: rvtond

view details

Beyang Liu

commit sha a91343a77bbca38f5a53aa1614eccab1094ded8b

podcast: update rvtond

view details

Austin Harshberger

commit sha 875ee32b23880d4b254a5d14ae37e8c77482d202

Adding Austin Harshberger to company/team/index.md (#1291) Adding new hire Austin Harshberger from Customer Engineering to company/team/index per [new hire onboarding tasks](https://about.sourcegraph.com/handbook/people-ops/onboarding#for-all-new-teammates). Please let me know if there are any typos or suggested edits, cheers!

view details

Austin Harshberger

commit sha 450ad2c42f108d3455ab555ae447511fc5366de8

Removing first sentence for Austin Harshberger due to typo (#1292) Just realized the first sentence of my bio was supposed to be third person and not first, so in everlasting embarrassment I am creating this PR to remove it so it's not eternalized in time 🤪

view details

aileenrose

commit sha 4da715da47a7196f9ffc09b863f5d2261d093bfb

Create component for Get Started (#1293) * Create component for Get Started * Lighten up gradient and update headings

view details

push time in 5 days

push eventsourcegraph/about

Christina Forney

commit sha 65a808ee6435ba742a875126de6343a4d864e548

Moving item to manager checklist

view details

push time in 5 days

push eventsourcegraph/about

Christina Forney

commit sha 631bbf0b29a839f8d63fb3dab5d64b048c0190c1

Apply suggestions from code review

view details

push time in 5 days

startedleits/MeetingBar

started time in 5 days

startedmichaelvillar/timer-app

started time in 5 days

Pull request review commentsourcegraph/about

Add items to the Product onboarding

 Welcome to Sourcegraph! As a member of the product team, it is your job to be th ## Product team member checklist  - Get to know our team and learn about Sourcegraph (company and product)+  - Schedule 30-min 1:1s with your manager for the first three days at Sourcegraph to keep up with your onboarding and ask all the questions you might have - Finish [general onboarding tasks](../../people-ops/onboarding/index.md#for-all-new-teammates)   - Set up your email filters, especially for GitHub and feedback - Get to know the product   - Complete of the [Engineering onboarding tasks](../../engineering/onboarding/index.md). Almost all of these are relevant to you.     - You will need to run Sourcegraph locally to test/validate work that engineering is doing, to provide early/often feedback.   - Review [product resources](../index.md#resources)   - [Products](https://about.sourcegraph.com/product)+  - Watch this [demo video](https://drive.google.com/file/d/1idbCnce5MIvtAV0GOOwgB68zQJB2WmZ9/view)+  - Read about [search queries](https://docs.sourcegraph.com/user/search) and perform your first searches
  - Read about [search queries](https://docs.sourcegraph.com/user/search) and perform your first searches.
AlicjaSuska

comment created time in 8 days

Pull request review commentsourcegraph/about

Add items to the Product onboarding

 Welcome to Sourcegraph! As a member of the product team, it is your job to be th ## Product team member checklist  - Get to know our team and learn about Sourcegraph (company and product)+  - Schedule 30-min 1:1s with your manager for the first three days at Sourcegraph to keep up with your onboarding and ask all the questions you might have - Finish [general onboarding tasks](../../people-ops/onboarding/index.md#for-all-new-teammates)   - Set up your email filters, especially for GitHub and feedback - Get to know the product   - Complete of the [Engineering onboarding tasks](../../engineering/onboarding/index.md). Almost all of these are relevant to you.     - You will need to run Sourcegraph locally to test/validate work that engineering is doing, to provide early/often feedback.   - Review [product resources](../index.md#resources)   - [Products](https://about.sourcegraph.com/product)+  - Watch this [demo video](https://drive.google.com/file/d/1idbCnce5MIvtAV0GOOwgB68zQJB2WmZ9/view)+  - Read about [search queries](https://docs.sourcegraph.com/user/search) and perform your first searches+  - Answer all the questions from the [Sales Onboarding Quiz](https://about.sourcegraph.com/handbook/sales/onboarding/quiz) and discuss the answers with your manager
  - Work through the questions from the [Sales Onboarding Quiz](https://about.sourcegraph.com/handbook/sales/onboarding/quiz) to make sure you understand key concepts. Discuss any questions you have or knowledge gaps with your manager.
AlicjaSuska

comment created time in 8 days

Pull request review commentsourcegraph/about

Add items to the Product onboarding

 Welcome to Sourcegraph! As a member of the product team, it is your job to be th ## Product team member checklist  - Get to know our team and learn about Sourcegraph (company and product)+  - Schedule 30-min 1:1s with your manager for the first three days at Sourcegraph to keep up with your onboarding and ask all the questions you might have

I think it makes most sense to put this under the above Manager checklist - that way the manager is blocking time to help onboard the new teammate throughout their first week.

  - Schedule daily check-ins for the first week at Sourcegraph to keep up with your onboarding and to create space for answering any questions that might come up.
AlicjaSuska

comment created time in 8 days

Pull request review commentsourcegraph/about

Add items to the Product onboarding

 Welcome to Sourcegraph! As a member of the product team, it is your job to be th ## Product team member checklist  - Get to know our team and learn about Sourcegraph (company and product)+  - Schedule 30-min 1:1s with your manager for the first three days at Sourcegraph to keep up with your onboarding and ask all the questions you might have - Finish [general onboarding tasks](../../people-ops/onboarding/index.md#for-all-new-teammates)   - Set up your email filters, especially for GitHub and feedback - Get to know the product   - Complete of the [Engineering onboarding tasks](../../engineering/onboarding/index.md). Almost all of these are relevant to you.     - You will need to run Sourcegraph locally to test/validate work that engineering is doing, to provide early/often feedback.   - Review [product resources](../index.md#resources)   - [Products](https://about.sourcegraph.com/product)+  - Watch this [demo video](https://drive.google.com/file/d/1idbCnce5MIvtAV0GOOwgB68zQJB2WmZ9/view)
  - Learn how the Customer Engineering team gives demos and talks about the product in the [product demo recording](https://drive.google.com/file/d/1idbCnce5MIvtAV0GOOwgB68zQJB2WmZ9/view).
AlicjaSuska

comment created time in 8 days

push eventsourcegraph/about

Loïc Guychard

commit sha c29efe8fe91704199ea8ca077f8090d339d57462

Fix T.K. start date (#1227)

view details

aileenrose

commit sha ee768d1725779ed799bfcda0269c93c7c8acef52

News updates plus fix header on uninstall page (#1222) * Fix header on uninstall. Plus add news item. * Add SVBusinessJournal

view details

aileenrose

commit sha 774a2b9b4b298dbd4e56678c961017fb3f8e2919

Add link to lightstep repo (#1224)

view details

Mimi E St Johns

commit sha fff3f302e4ebb79eef5d9fcbf7748eded9a31391

Add Mimi to team page (#1215)

view details

Nick Snyder

commit sha 032ceb7079262b7ba26d7113faf3a48a2e06a83d

Link to Aida

view details

Nick Snyder

commit sha e449f04ecc45deacaaa282223dce93e65e536ed0

fix link

view details

Nick Snyder

commit sha a9550f680abf88d62d4865477146d69a0a3fdf30

What good interview documentation looks like (#1229)

view details

Beyang Liu

commit sha 5f59ad992797362cd18a2523f12f68e601a5082b

podcast: fix first-render for other tabs

view details

Nick Snyder

commit sha fad6b4b44935c0581cb049fbcff7df7b034fe096

We are hiring a manager for the web team

view details

Quinn Slack

commit sha c322c6392cf7b533c0b3c3e2411754fcc2fc2657

Goals (not OKRs): continuous, fewer in number, less strict format (#1177) Why not just use OKRs? - Using OKRs implies a process where the goals are defined at the start of a time period and don't change until the start of the next time period. This makes people reluctant to change their goals when they are the wrong goals, which is a bad incentive. Realizing the goals are wrong and quickly changing them is way better than hitting the wrong goals. - [We don't like jargon and acronyms](https://about.sourcegraph.com/handbook/communication/style_guide#jargon-and-acronyms), and "OKR" is both. Why say "objective" when you can say "goal"? Why say "key result" and not just "result"? Questions like these make people think that there's some special science behind OKRs, when really the hard part is the fundamentally hard problem of coming up with the right goals. - There are so many ways to "do [OKRs](https://en.wikipedia.org/wiki/OKR)." Why name the overall goal-setting process after something that defines just a small part of the overall process?

view details

Quinn Slack

commit sha d4e78a07086ed8b9681116a49e9b2a7d4a62f5c2

just targeting metrics is OK

view details

Beyang Liu

commit sha e44e24ca8f09b759077dcac191327a75aab8318f

podcast: add acknowledgements

view details

Beyang Liu

commit sha 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611

blog: update title

view details

Beyang Liu

commit sha 652647fa49fb18ebf01c503c7dacc2fb76ba98b1

podcast: publish yves and john

view details

Beyang Liu

commit sha 46e24eb35a2c074ad119fcf4bade0c8339843436

Revert "blog: update title" This reverts commit 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611.

view details

Beyang Liu

commit sha 5b67c89154d2d6c403001ac8eb72565adc1d68e9

blog: update url

view details

Beyang Liu

commit sha 1e8b81837509411e831e7f2f579ebdca915cd416

blog: adjust image style

view details

Dax McDonald

commit sha d3598fe63e36f1f4bf7d22bae0853253c76effe6

Update Sourcegraph.com deletion playbook (#1198)

view details

Tomás Senart

commit sha dea43e6addbe3c95cbd4199bde99b92ac4369842

cloud: Add Goals section (#1226) As per discussion on https://threads.com/34382402992 and a live meeting to come up with the longer term goals for the team.

view details

Dax McDonald

commit sha 5e2013be2779c5083c90bb3747ccfc3007048f83

Update for cloud cluster (#1231)

view details

push time in 8 days

push eventsourcegraph/about

Christina Forney

commit sha 6969375756c180fd25a66bd8a23fac4f87be699f

Product team goals (#1262)

view details

push time in 8 days

delete branch sourcegraph/about

delete branch : cf/goals

delete time in 8 days

PR merged sourcegraph/about

Product team goals
+77 -0

0 comment

2 changed files

christinaforney

pr closed time in 8 days

delete branch sourcegraph/about

delete branch : cf/engineering-productboard

delete time in 11 days

push eventsourcegraph/about

Christina Forney

commit sha 2d29621f552b31cb426cba09de2fd438e22da5f1

Add productboard to the manager checklist for a new hire (#1274)

view details

push time in 11 days

create barnchsourcegraph/about

branch : cf/engineering-productboard

created branch time in 11 days

push eventsourcegraph/about

Christina Forney

commit sha e7afa9b649f4613bb4746d6f0e509e83b4d5bf9d

Add clarification about new files, remove docsite specifics (#1261) There is now a simple `make serve` command that will run docsite, and the instructions for running were in two places. This points folks at the README as the source of truth.

view details

push time in 12 days

delete branch sourcegraph/about

delete branch : cf/editing-handbook

delete time in 12 days

PR merged sourcegraph/about

Reviewers
Add clarification about new files, remove docsite specifics

There is now a simple make serve command that will run docsite, and the instructions for running were in two places. This points folks at the README as the source of truth.

+3 -19

0 comment

1 changed file

christinaforney

pr closed time in 12 days

PR opened sourcegraph/about

Product team goals
+77 -0

0 comment

2 changed files

pr created time in 12 days

create barnchsourcegraph/about

branch : cf/goals

created branch time in 12 days

PR opened sourcegraph/about

Reviewers
Add clarification about new files, remove docsite specifics

There is now a simple make serve command that will run docsite, and the instructions for running were in two places. This points folks at the README as the source of truth.

+3 -19

0 comment

1 changed file

pr created time in 12 days

create barnchsourcegraph/about

branch : cf/editing-handbook

created branch time in 12 days

pull request commentsourcegraph/about

Design handoff process

@christinaforney I've merged my PR regarding headers and design files handling yesterday. That's probably why they overlap. In this one only part about the hand-off is new :)

Thanks! I just merged in master to resolve the conflicts :)

rrhyne

comment created time in 12 days

push eventsourcegraph/about

aileenrose

commit sha ee768d1725779ed799bfcda0269c93c7c8acef52

News updates plus fix header on uninstall page (#1222) * Fix header on uninstall. Plus add news item. * Add SVBusinessJournal

view details

aileenrose

commit sha 774a2b9b4b298dbd4e56678c961017fb3f8e2919

Add link to lightstep repo (#1224)

view details

Mimi E St Johns

commit sha fff3f302e4ebb79eef5d9fcbf7748eded9a31391

Add Mimi to team page (#1215)

view details

Nick Snyder

commit sha 032ceb7079262b7ba26d7113faf3a48a2e06a83d

Link to Aida

view details

Nick Snyder

commit sha e449f04ecc45deacaaa282223dce93e65e536ed0

fix link

view details

Nick Snyder

commit sha a9550f680abf88d62d4865477146d69a0a3fdf30

What good interview documentation looks like (#1229)

view details

Beyang Liu

commit sha 5f59ad992797362cd18a2523f12f68e601a5082b

podcast: fix first-render for other tabs

view details

Nick Snyder

commit sha fad6b4b44935c0581cb049fbcff7df7b034fe096

We are hiring a manager for the web team

view details

Quinn Slack

commit sha c322c6392cf7b533c0b3c3e2411754fcc2fc2657

Goals (not OKRs): continuous, fewer in number, less strict format (#1177) Why not just use OKRs? - Using OKRs implies a process where the goals are defined at the start of a time period and don't change until the start of the next time period. This makes people reluctant to change their goals when they are the wrong goals, which is a bad incentive. Realizing the goals are wrong and quickly changing them is way better than hitting the wrong goals. - [We don't like jargon and acronyms](https://about.sourcegraph.com/handbook/communication/style_guide#jargon-and-acronyms), and "OKR" is both. Why say "objective" when you can say "goal"? Why say "key result" and not just "result"? Questions like these make people think that there's some special science behind OKRs, when really the hard part is the fundamentally hard problem of coming up with the right goals. - There are so many ways to "do [OKRs](https://en.wikipedia.org/wiki/OKR)." Why name the overall goal-setting process after something that defines just a small part of the overall process?

view details

Quinn Slack

commit sha d4e78a07086ed8b9681116a49e9b2a7d4a62f5c2

just targeting metrics is OK

view details

Beyang Liu

commit sha e44e24ca8f09b759077dcac191327a75aab8318f

podcast: add acknowledgements

view details

Beyang Liu

commit sha 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611

blog: update title

view details

Beyang Liu

commit sha 652647fa49fb18ebf01c503c7dacc2fb76ba98b1

podcast: publish yves and john

view details

Beyang Liu

commit sha 46e24eb35a2c074ad119fcf4bade0c8339843436

Revert "blog: update title" This reverts commit 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611.

view details

Beyang Liu

commit sha 5b67c89154d2d6c403001ac8eb72565adc1d68e9

blog: update url

view details

Beyang Liu

commit sha 1e8b81837509411e831e7f2f579ebdca915cd416

blog: adjust image style

view details

Dax McDonald

commit sha d3598fe63e36f1f4bf7d22bae0853253c76effe6

Update Sourcegraph.com deletion playbook (#1198)

view details

Tomás Senart

commit sha dea43e6addbe3c95cbd4199bde99b92ac4369842

cloud: Add Goals section (#1226) As per discussion on https://threads.com/34382402992 and a live meeting to come up with the longer term goals for the team.

view details

Dax McDonald

commit sha 5e2013be2779c5083c90bb3747ccfc3007048f83

Update for cloud cluster (#1231)

view details

Dan Adler

commit sha a2930fd9ac31c7d003a390b29d9f44a42c2446ac

Add sales-to-CE handover process docs, move license keys docs to CE handbook (#1195) * Add sales-to-CE handover process docs, move license keys docs to CE handbook * Update handbook/sales/sales_to_ce_handover.md Co-authored-by: Eric Brody-Moore <ericbm@sourcegraph.com> * Tweak license key docs * Update link Co-authored-by: Eric Brody-Moore <ericbm@sourcegraph.com>

view details

push time in 12 days

pull request commentsourcegraph/about

Design handoff process

Is this PR different from https://github.com/sourcegraph/about/pull/1187? It seems like there is some overlap.

rrhyne

comment created time in 13 days

push eventsourcegraph/about

Christina Forney

commit sha 1256c1fc25cb760cef0333ff80382e46e298c3c0

Formatting and adding final review section (#1225)

view details

push time in 13 days

delete branch sourcegraph/about

delete branch : cf/design-final-review

delete time in 13 days

PR merged sourcegraph/about

Reviewers
Formatting and adding final review section

Review with "ignore whitespace" on, so you can more clearly see the change.

+148 -119

0 comment

1 changed file

christinaforney

pr closed time in 13 days

push eventsourcegraph/about

Loïc Guychard

commit sha c29efe8fe91704199ea8ca077f8090d339d57462

Fix T.K. start date (#1227)

view details

aileenrose

commit sha ee768d1725779ed799bfcda0269c93c7c8acef52

News updates plus fix header on uninstall page (#1222) * Fix header on uninstall. Plus add news item. * Add SVBusinessJournal

view details

aileenrose

commit sha 774a2b9b4b298dbd4e56678c961017fb3f8e2919

Add link to lightstep repo (#1224)

view details

Mimi E St Johns

commit sha fff3f302e4ebb79eef5d9fcbf7748eded9a31391

Add Mimi to team page (#1215)

view details

Nick Snyder

commit sha 032ceb7079262b7ba26d7113faf3a48a2e06a83d

Link to Aida

view details

Nick Snyder

commit sha e449f04ecc45deacaaa282223dce93e65e536ed0

fix link

view details

Nick Snyder

commit sha a9550f680abf88d62d4865477146d69a0a3fdf30

What good interview documentation looks like (#1229)

view details

Beyang Liu

commit sha 5f59ad992797362cd18a2523f12f68e601a5082b

podcast: fix first-render for other tabs

view details

Nick Snyder

commit sha fad6b4b44935c0581cb049fbcff7df7b034fe096

We are hiring a manager for the web team

view details

Quinn Slack

commit sha c322c6392cf7b533c0b3c3e2411754fcc2fc2657

Goals (not OKRs): continuous, fewer in number, less strict format (#1177) Why not just use OKRs? - Using OKRs implies a process where the goals are defined at the start of a time period and don't change until the start of the next time period. This makes people reluctant to change their goals when they are the wrong goals, which is a bad incentive. Realizing the goals are wrong and quickly changing them is way better than hitting the wrong goals. - [We don't like jargon and acronyms](https://about.sourcegraph.com/handbook/communication/style_guide#jargon-and-acronyms), and "OKR" is both. Why say "objective" when you can say "goal"? Why say "key result" and not just "result"? Questions like these make people think that there's some special science behind OKRs, when really the hard part is the fundamentally hard problem of coming up with the right goals. - There are so many ways to "do [OKRs](https://en.wikipedia.org/wiki/OKR)." Why name the overall goal-setting process after something that defines just a small part of the overall process?

view details

Quinn Slack

commit sha d4e78a07086ed8b9681116a49e9b2a7d4a62f5c2

just targeting metrics is OK

view details

Beyang Liu

commit sha e44e24ca8f09b759077dcac191327a75aab8318f

podcast: add acknowledgements

view details

Beyang Liu

commit sha 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611

blog: update title

view details

Beyang Liu

commit sha 652647fa49fb18ebf01c503c7dacc2fb76ba98b1

podcast: publish yves and john

view details

Beyang Liu

commit sha 46e24eb35a2c074ad119fcf4bade0c8339843436

Revert "blog: update title" This reverts commit 46ef6dac24c4e365cbf27bd8cd8b6dc47a81b611.

view details

Beyang Liu

commit sha 5b67c89154d2d6c403001ac8eb72565adc1d68e9

blog: update url

view details

Beyang Liu

commit sha 1e8b81837509411e831e7f2f579ebdca915cd416

blog: adjust image style

view details

Dax McDonald

commit sha d3598fe63e36f1f4bf7d22bae0853253c76effe6

Update Sourcegraph.com deletion playbook (#1198)

view details

Tomás Senart

commit sha dea43e6addbe3c95cbd4199bde99b92ac4369842

cloud: Add Goals section (#1226) As per discussion on https://threads.com/34382402992 and a live meeting to come up with the longer term goals for the team.

view details

Dax McDonald

commit sha 5e2013be2779c5083c90bb3747ccfc3007048f83

Update for cloud cluster (#1231)

view details

push time in 13 days

push eventsourcegraph/about

Christina Forney

commit sha 966402a3cf29260b089e8b10d9c662f69956db4a

Update to use image paths

view details

push time in 13 days

push eventsourcegraph/about

Christina Forney

commit sha 41761fa8e519c0cfb49df9e97cb5716cc6d541b8

Updating hero images and github issue at top of posts

view details

push time in 13 days

push eventsourcegraph/about

Marek

commit sha 6142fe77d657f10d6a30add926f9aadbc01ac371

Add to section on flaky tests (#1238) Expand the flaky tests section with a definition and an explanation of why they are undesirable

view details

Quinn Slack

commit sha 041d1db0e6d4d532d03d079e52f010cb1e6233e2

team can own a goal (#1239)

view details

adamfrankl2015

commit sha e90e5405f9812a839b7ba03594a10a08dfad538b

Update index.md

view details

adamfrankl2015

commit sha fbec57832af1f27ea44a359e36e66cb83d321c62

Update index.md

view details

adamfrankl2015

commit sha 6e7e0163119c1e2e72ceaa93fa9d60f25252b1db

Update index.md

view details

adamfrankl2015

commit sha 2d186c57d798ac21f4fd22e81ab5884b89b1de81

Update index.md

view details

adamfrankl2015

commit sha 45e983211ad2abb5c1787f1dc6c6a04e5b183e5c

Update index.md

view details

Christina Forney

commit sha 3d9c9e8e2e6bb50a2b3afb8d72662db4b79267e3

Update docs so retrospectives are documented in one place (#1240)

view details

adamfrankl2015

commit sha 560e3e0cb5653877c8b1ca898664f5c8213d281d

Update index.md

view details

adamfrankl2015

commit sha bba6744f5d32f163ff06c2c992efbbc2def752ce

Update index.md

view details

adamfrankl2015

commit sha ff5d4d03c494d9547921effd3bf5bbbf0712be2f

Update org_chart.md

view details

adamfrankl2015

commit sha 4d16b5722d6b516a703e6e1f392a524beb21aff9

Update index.md

view details

Noemi Mercado

commit sha e828c6ed32e2b8a0ca412fc18ed5bff1b397555b

Update index.md

view details

AlicjaSuska

commit sha 840ea7b5862869e9d16580d9561c7fda75c7d81a

Add Working with design files + heading update (#1187) * Add Working with design files + heading update I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools. In addition, I've changed slightly the formatting of the 'Process segments' section - using bold text for the main steps in the process increases the readability of this document. Please, share your feedback regarding both the content and the form :) Thank you! * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Add Pages to 'File structure' according Changes according to Rob's suggestion. @rrhyne please review. Thank you! Co-authored-by: Rob Rhyne <rob@sourcegraph.com> Co-authored-by: Christina Forney <christina@sourcegraph.com>

view details

Laureen Hudson

commit sha 58c9d7a09773f931f310cdbc1854baf934b1aa37

Lh/3 18 release blogs (#1242) * creation of blogs and images for the 3.18 release * metatag fixes Co-authored-by: LaureenH <laureen.hudson@braingu.com>

view details

Laureen Hudson

commit sha 4e200d1159a65e677b3f1196907785d702262b65

Revert "Lh/3 18 release blogs (#1242)" (#1244) This reverts commit 58c9d7a09773f931f310cdbc1854baf934b1aa37.

view details

Christina Forney

commit sha 3568262a665bc1781c330c123c5144fcc21b67b6

Lh/3 18 release blogs (#1246) * creation of blogs and images for the 3.18 release * metatag fixes * Fixing bad paths, and formatting fixes to publish Co-authored-by: LaureenH <laureen.hudson@braingu.com> Co-authored-by: Laureen Hudson <52249965+LaureenH@users.noreply.github.com>

view details

Christina Forney

commit sha ad976f1c60bd3cf426c2623ace2f03c7c41f5f82

Merge remote-tracking branch 'origin/master' into 3.18-release-blogs

view details

push time in 13 days

push eventsourcegraph/about

Christina Forney

commit sha 104bacf9504ffc2cd4ed0fab7c0e1cf6c3686662

Fixing bad paths, and formatting fixes to publish

view details

push time in 13 days

create barnchsourcegraph/about

branch : lh/3-18-release-blogs

created branch time in 13 days

pull request commentsourcegraph/about

3.18 release blogs

  • On the combo post blog, I could not get the video to display correctly in preview even though the example I stole it from worked just fine. The video ID is correct. ???

See the updated snippet I added as suggestion (and the blog post template to have access to this). You should use the embed URL for the video.

  • The Android and Python search page images are huge for some reason in the custom search pages blog

You should resize the images before uploading them for two reasons: 1. size on the page 2. Bloat to the repository due to the image size (also see my comments above about not adding images to this repository).

kghopson

comment created time in 13 days

Pull request review commentsourcegraph/about

3.18 release blogs

+---+title: 'Small but mighty new features'+author: 'Loïc Guychard, Adam Harvey, Eric Fritz'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: small-and-mighty-features+heroImage: https://about.sourcegraph.com/sourcegraph-mark.png+published: true+---+## Improved add / update repository flow for users trying private versions of Sourcegraph (#[11044](https://github.com/sourcegraph/sourcegraph/issues/11044))++Developer: [Loïc Guychard](https://github.com/lguychard)++When you’re getting started setting up a Sourcegraph instance, it can be confusing to start the process of adding a code host. You may not be sure that Sourcegraph+will protect the privacy of your data because there is no communication about how the software will interact with your repositories. We’ve added a new language in+Sourcegraph 3.18 that clarifies what information we access within the Sourcegraph UI so you can move forward with confidence.++![Add repository flow](./images/add-repository-flow.png "Privacy feedback in Sourcegraph UI")++## Campaigns now support GitLab (#[11586](https://github.com/sourcegraph/sourcegraph/issues/11586))+Developer: [Adam Harvey](https://github.com/LawnGnome)++You asked, we implemented. We’ve received a lot of feedback from developers using GitLab as their code hosts that campaign capabilities would be useful, so we added+them in the Sourcegraph 3.18 release. This makes campaigns available to more organizations and helps make Sourcegraph more universal. See Adam’s introductory video below:++[![Campaigns for Gitlab](https://img.youtube.com/vi/KatiVJ4D3H4/maxresdefault.jpg)](https://youtu.be/KatiVJ4D3H4)

You can find this by looking at the blog post template in the handbook in raw format: https://raw.githubusercontent.com/sourcegraph/about/master/handbook/product/product_management/release_blog_post_template.md

kghopson

comment created time in 13 days

Pull request review commentsourcegraph/about

3.18 release blogs

+---+title: 'Small but mighty new features'+author: 'Loïc Guychard, Adam Harvey, Eric Fritz'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: small-and-mighty-features+heroImage: https://about.sourcegraph.com/sourcegraph-mark.png+published: true+---+## Improved add / update repository flow for users trying private versions of Sourcegraph (#[11044](https://github.com/sourcegraph/sourcegraph/issues/11044))++Developer: [Loïc Guychard](https://github.com/lguychard)++When you’re getting started setting up a Sourcegraph instance, it can be confusing to start the process of adding a code host. You may not be sure that Sourcegraph+will protect the privacy of your data because there is no communication about how the software will interact with your repositories. We’ve added a new language in+Sourcegraph 3.18 that clarifies what information we access within the Sourcegraph UI so you can move forward with confidence.++![Add repository flow](./images/add-repository-flow.png "Privacy feedback in Sourcegraph UI")++## Campaigns now support GitLab (#[11586](https://github.com/sourcegraph/sourcegraph/issues/11586))+Developer: [Adam Harvey](https://github.com/LawnGnome)++You asked, we implemented. We’ve received a lot of feedback from developers using GitLab as their code hosts that campaign capabilities would be useful, so we added+them in the Sourcegraph 3.18 release. This makes campaigns available to more organizations and helps make Sourcegraph more universal. See Adam’s introductory video below:++[![Campaigns for Gitlab](https://img.youtube.com/vi/KatiVJ4D3H4/maxresdefault.jpg)](https://youtu.be/KatiVJ4D3H4)

You should use the following embed code for adding videos (you will need to update the URLs below.

<p class="container">
  <div style="padding:56.25% 0 0 0;position:relative;">
    <iframe src="https://www.youtube.com/embed/{VIDEO_ID}" style="position:absolute;top:0;left:0;width:100%;height:100%;" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>
  </div>
  <p style="text-align: center"><a href="https://youtu.be/{VIDEO_ID}" target="_blank">View on YouTube</a></p>
</p>
kghopson

comment created time in 13 days

Pull request review commentsourcegraph/about

3.18 release blogs

+title: 'Getting notified about the health of Sourcegraph is even easier'+author: 'Robert'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: sourcegraph-health-notification+heroImage: https://about.sourcegraph.com/sourcegraph-mark.png+published: true++## Getting notified about the health of Sourcegraph is even easier

Title should be an h1

# Getting notified about the health of Sourcegraph is even easier
kghopson

comment created time in 13 days

Pull request review commentsourcegraph/about

3.18 release blogs

+title: 'Custom search pages on Sourcegraph Cloud'+author: 'Farhan'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: custom-search-pages+heroImage: https://about.sourcegraph.com/sourcegraph-mark.png+published: true+---+## Custom search pages on Sourcegraph Cloud (#[11526](https://github.com/sourcegraph/sourcegraph/issues/11526))

Title should be an h1

# Custom search pages on Sourcegraph Cloud (#[11526](https://github.com/sourcegraph/sourcegraph/issues/11526))
kghopson

comment created time in 13 days

Pull request review commentsourcegraph/about

3.18 release blogs

+---+title: 'Small but mighty new features'+author: 'Loïc Guychard, Adam Harvey, Eric Fritz'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: small-and-mighty-features+heroImage: https://about.sourcegraph.com/sourcegraph-mark.png+published: true+---+## Improved add / update repository flow for users trying private versions of Sourcegraph (#[11044](https://github.com/sourcegraph/sourcegraph/issues/11044))

Title should be an h1

# Improved add / update repository flow for users trying private versions of Sourcegraph (#[11044](https://github.com/sourcegraph/sourcegraph/issues/11044))
kghopson

comment created time in 13 days

pull request commentsourcegraph/about

Revert "Lh/3 18 release blogs"

@LaureenH - Is the reason you reverted to unpublish the blogs? Instead you could have just changed the metadata to "published: false" and it would not show up on the site.

LaureenH

comment created time in 13 days

push eventsourcegraph/about

Christina Forney

commit sha f5f75a7857a11d93d4ed7a28dcc21a836f9f488f

Add diagram and updates

view details

push time in 14 days

push eventsourcegraph/about

Christina Forney

commit sha 3d9c9e8e2e6bb50a2b3afb8d72662db4b79267e3

Update docs so retrospectives are documented in one place (#1240)

view details

push time in 14 days

delete branch sourcegraph/about

delete branch : cf/retrospective

delete time in 14 days

PR merged sourcegraph/about

Reviewers
Update docs so retrospectives are documented in one place

There was some confusion on how to do a retrospective because it was documented in two places. I moved the engineering specific information to a section on the top-level retrospectives documentation.

+34 -30

0 comment

2 changed files

christinaforney

pr closed time in 14 days

PR opened sourcegraph/about

Reviewers
Update docs so retrospectives are documented in one place

There was some confusion on how to do a retrospective because it was documented in two places. I moved the engineering specific information to a section on the top-level retrospectives documentation.

+34 -30

0 comment

2 changed files

pr created time in 14 days

create barnchsourcegraph/about

branch : cf/retrospective

created branch time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

++---+title: 'New C++ precise code intelligence solution'+author: 'Garo Brik'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: indexed-non-master-branches++---+## New C++ precise code intelligence solution (#[10175](https://github.com/sourcegraph/sourcegraph/issues/10175))

Should this be a H1 (i.e. #)?

LaureenH

comment created time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

+---+title: 'Search across multiple revisions of the same repository'+author: 'Keegan Carruthers-Smith'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: indexed-non-master-branches++---++### Search across multiple revisions of the same repository  (#[11668](https://github.com/sourcegraph/sourcegraph/issues/11668))++Developer: [Keegan](https://github.com/keegancsmith)++Often, you need to understand the differences between code at different branches (especially for release branches that have diverged).++In Sourcegraph 3.18, you can now search across multiple revisions of the same repository by listing multiple branch names (or other revision specifications) separated by `:` in your query. So to search across multiple specific branches, you’d use something like `repo:myrepo@branch1:branch2:branch2`. To search all branches, use `repo:myrepo@*refs/heads/`.++For example, a search over Sourcegraph versions 3.16 & 3.17 would look something like this++![search over Sourcegraph versions 3.16 and 3.17](images/searchacrossrev1.png)+++A search over all branches, using [@*refs/heads/](https://sourcegraph.com/search?q=repo:%5Egithub.com/sourcegraph/sourcegraph%24%40*refs/heads/+CONTAINER_ID&patternType=literal&case=yes) would look like this++![search over all branches using @*refs/heads/](images/searchacrossrev2.png)+++Be aware that searching over all branches may be slow. The cost of searching a branch is the same cost as searching a repository. To speed this up, ensure that branches are indexed with our experimental [Indexed non-master branches” feature](add link).

Is the link still WIP?

LaureenH

comment created time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

+

Same feedback on this file as in the first one.

LaureenH

comment created time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

++---+title: 'New C++ precise code intelligence solution'+author: 'Garo Brik'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: indexed-non-master-branches++---

I think you're missing two metadata items here:

heroImage: https://about.sourcegraph.com/sourcegraph-mark.png
published: true
LaureenH

comment created time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

+

Extra newline

LaureenH

comment created time in 14 days

Pull request review commentsourcegraph/about

creation of blogs and images for the 3.18 release

++---+title: 'Indexed non-master branches'+author: 'Keegan Carruthers-Smith'+publishDate: 2020-07-20T00:00-07:00+tags: ["blog"]+slug: indexed-non-master-branches++---++## Indexed non-master branches (#[6728](https://github.com/sourcegraph/sourcegraph/issues/6728))++Developer: [Keegan](https://github.com/keegancsmith)++Developers often want to search code that isn’t their default branch, like long-lived release branches or important tags. We added version contexts in Sourcegraph 3.16  to make it easier for developers to search a collection of repositories at specified revisions. However, Sourcegraph only indexed your default branch. This meant that when searching a non-default branch for the first time, Sourcegraph would not consult an index, leading to potentially multi-second searches. Or in the case of very large collections of code, time out. In Sourcegraph 3.18, we now use an index on the default branch to speed up these search operations, such that they happen in under a second, and have added the capability to index branches other than the default branch.++[HEAD](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefHEADaHEAD) is a [symbolic reference](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefsymrefasymref) to the current branch in git. The HEAD of a repository you clone is your default branch (by default “master” in Git). So “HEAD” in Sourcegraph is your default branch.+++### Example configuration++Branches:++![alt_text](images/expfeatures1.png "image_tooltip")

Should this have proper alt text and tooltip text? Same with image below.

LaureenH

comment created time in 14 days

PR opened sourcegraph/about

Product process and ownership
+48 -2

0 comment

2 changed files

pr created time in 15 days

create barnchsourcegraph/about

branch : cf/product-process

created branch time in 15 days

push eventsourcegraph/about

Christina Forney

commit sha 361d91e686c15c27ddaa2c46c9f10a5e451d8ee1

Updating product priorities

view details

push time in 15 days

push eventsourcegraph/sourcegraph

Christina Forney

commit sha ce4174187b9b0c929d8b2d0a43bdf3d5237fafd4

Fixing eslint

view details

push time in 18 days

push eventsourcegraph/sourcegraph

Christina Forney

commit sha f36855c154d20e6d2e477637b5d26d9181209ff8

Fixing prettier complaints

view details

push time in 18 days

Pull request review commentsourcegraph/about

Formatting and adding final review section

 While asynchronous communication is a core attribute of remote work, key moments  ## Process segments -- Ideation-  - This is generally represented by a kickoff meeting with interested parties. Kickoff meetings should generally include representatives of the following parties:-      - The product manager-      - Developers working on the project-      - Designers-      - Sales, ops and customer engineering staff who have insight into how this affects users-      - Customers if available-      - Stakeholders as required-  - Tools-      - We are experimenting with [miro.com](https://miro.com/) as an ideation tool-      - Figma.com can be used to generate mood boards+### Ideation++- This is generally represented by a kickoff meeting with interested parties. Kickoff meetings should generally include representatives of the following parties:+    - The product manager+    - Developers working on the project+    - Designers+    - Sales, ops and customer engineering staff who have insight into how this affects users+    - Customers if available+    - Stakeholders as required+- Tools+    - We are experimenting with [miro.com](https://miro.com/) as an ideation tool+    - Figma.com can be used to generate mood boards - Research-  - Interview internal users-      - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented-  - Interview external users-      - Where the project requires and time permits, conduct research with these users to inform your designs-  - Customer requests and support tickets-      - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)-  - Analogous designs-  - Competitive designs-  - Usability tests-    - When updating existing product features, first conduct usability tests to inform redesign decisions-  - Process-      - A GitHub issue should be created to track the work-      - Research is conducted according to requirements-      - Findings publishing and review-        - Findings should be detailed in a Google doc and announced in the corresponding team channel or #product on Slack-        - Findings should contain a clear summary, links to resources and supporting data-        - Conduct a synchronous review meeting with key stakeholders based on the size of project or importance of findings-      - Schedule and conduct a presentation meeting with stakeholders where necessary-  - Tools-      - Google Docs-      - Google Forms for polls-      - UserTesting.com-      - Maze.design-- Wireframes-  - Wireframes should utilize the Sourcegraph Figma component system-  - Wireframes should generally utilize realistic data and text for each element. In cases where many elements are required, ‘lorem epsum’ placeholder text will suffice if the initial or prominent elements are real data.-  - Process-      - A GitHub issue should be created to track the work-          - Label the issue with the design and/or ux label-          - TBD - how do we replicate pull request reviewers?-      - Wireframes are produced in Figma-      - Wireframes are announced in Slack and linked in the GitHub issue well before they are complete for review-      - Wireframes are hallway tested with internal users and product managers-      - Schedule and conduct a presentation meeting-      - Stakeholders will approve the GitHub issue indicating the designs are ready for the next phase-  - Checklist-      - Ensure designs meet Jacob Nielsen's [ten usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)+- Interview internal users+    - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented+- Interview external users+    - Where the project requires and time permits, conduct research with these users to inform your designs+- Customer requests and support tickets+    - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)+- Analogous designs+- Competitive designs+- Usability tests+  - When updating existing product features, first conduct usability tests to inform redesign decisions+- Process+    - A GitHub issue should be created to track the work+    - Research is conducted according to requirements+    - Findings publishing and review+      - Findings should be detailed in a Google doc and announced in the corresponding team channel or #product on Slack+      - Findings should contain a clear summary, links to resources and supporting data+      - Conduct a synchronous review meeting with key stakeholders based on the size of project or importance of findings+    - Schedule and conduct a presentation meeting with stakeholders where necessary+- Tools+    - Google Docs+    - Google Forms for polls+    - UserTesting.com+    - Maze.design++### Wireframes++- Wireframes should utilize the Sourcegraph Figma component system+- Wireframes should generally utilize realistic data and text for each element. In cases where many elements are required, ‘lorem epsum’ placeholder text will suffice if the initial or prominent elements are real data.+- Process+    - A GitHub issue should be created to track the work+        - Label the issue with the design and/or ux label+        - TBD - how do we replicate pull request reviewers?+    - Wireframes are produced in Figma+    - Wireframes are announced in Slack and linked in the GitHub issue well before they are complete for review+    - Wireframes are hallway tested with internal users and product managers+    - Schedule and conduct a presentation meeting+    - Stakeholders will approve the GitHub issue indicating the designs are ready for the next phase+- Checklist+    - Ensure designs meet Jacob Nielsen's [ten usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)+    - Has the change’s effect on the CLI been considered?+        - Does the language in the UI map to the language in the CLI?+    - Enterprise / Cloud+    - Signed in vs. anonymous user+    - User permissions+    - Interactive mode / plain text mode+    - TBD - add a standard UX checklist+- Tools+    - Figma++### Testing++- Process+    - A GitHub issue should be created to track the work+    - Testing is conducted according to requirements+    - Publish testing results summary to google drive+    - Announce results in slack+    - Create a GitHub issue to address items in the test results+- Tools+    - Maze.design+    - UserTesting.org++### Visual design++- Visual design should utilize the Sourcegraph’s Figma based component system+- Dark compositions will be created for each major design+- If new components are required, components will be created in the file itself, not the component system+- Improvements to the Sourcegraph user experience should consider the following in every change:       - Has the change’s effect on the CLI been considered?-          - Does the language in the UI map to the language in the CLI?+      - Does the language in the UI map to the language in the CLI?+      - Does the documentation reflect the change?+      - Light mode / Dark mode       - Enterprise / Cloud       - Signed in vs. anonymous user       - User permissions       - Interactive mode / plain text mode-      - TBD - add a standard UX checklist-  - Tools-      - Figma-- Testing-  - Process-      - A GitHub issue should be created to track the work-      - Testing is conducted according to requirements-      - Publish testing results summary to google drive-      - Announce results in slack-      - Create a GitHub issue to address items in the test results-  - Tools-      - Maze.design-      - UserTesting.org-- Visual design-  - Visual design should utilize the Sourcegraph’s Figma based component system-  - Dark compositions will be created for each major design-  - If new components are required, components will be created in the file itself, not the component system-  - Improvements to the Sourcegraph user experience should consider the following in every change:-        - Has the change’s effect on the CLI been considered?-        - Does the language in the UI map to the language in the CLI?-        - Does the documentation reflect the change?-        - Light mode / Dark mode-        - Enterprise / Cloud-        - Signed in vs. anonymous user-        - User permissions-        - Interactive mode / plain text mode-  - Process-      - A GitHub issue should be created to track the work-      - Designs are produced in Figma-      - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review-      - Ensure designs meet the visual design checklist:-        - Ensure spacing is consistent and matches the 8pt grid system-        - Ensure text, colors and other sytles match existing styles, if possible. -          - Introduce new text styles only if really necessary.-          - If adding new styles, ensure that they meet the accessibility standards and add them to the design system -        - Review designs for accessability:-          - Color blind check-          - Contrast check should meet AA standard for small text-      - Schedule and conduct a design presentation meeting if the size of the project requires-      - Receive signoff from stakeholders-      - If components were created in the visual design process, when the designs are signed off on, those components will be moved to the Sourcegraph component system-      - Prepare redlines or an interaction delivery writeup for the engineers. Consider the following:-          - Margin and padding-          - Animation-          - Links and hover states-      - Describe expected behavior of layout for tablet and moble screensizes-        - Due to the low number of mobile and table visitors (< 3%) design comps for these sizes are generally not required -      - Schedule a meeting with engineers to discuss the interaction-  - Tools-      - Figma-- Metrics collection:-  - In the RFC process, the definition of success will include items which can be measured and evaluated-  - Involve the business operations team in determining what metrics to track and how they are tracked-  - Work with engineers to add the required eventLog tracking-  - Tools-      - Looker-      - Google analytics-- Refinement-  - Designers will review metrics and determine if their designs are meeting objectives set for them.-  - If areas for improvement are found, tickets will be created to document the change required to improve the issue+- Process+    - A GitHub issue should be created to track the work+    - Designs are produced in Figma+    - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review+    - Ensure designs meet the visual design checklist:+      - Ensure spacing is consistent and matches the 8pt grid system+      - Ensure text, colors and other sytles match existing styles, if possible. +        - Introduce new text styles only if really necessary.+        - If adding new styles, ensure that they meet the accessibility standards and add them to the design system +      - Review designs for accessability:+        - Color blind check+        - Contrast check should meet AA standard for small text+    - Schedule and conduct a design presentation meeting if the size of the project requires+    - Receive signoff from stakeholders+    - If components were created in the visual design process, when the designs are signed off on, those components will be moved to the Sourcegraph component system+    - Prepare redlines or an interaction delivery writeup for the engineers. Consider the following:+        - Margin and padding+        - Animation+        - Links and hover states+    - Describe expected behavior of layout for tablet and moble screensizes+      - Due to the low number of mobile and table visitors (< 3%) design comps for these sizes are generally not required +    - Schedule a meeting with engineers to discuss the interaction+- Tools+    - Figma++### Metrics collection++- In the RFC process, the definition of success will include items which can be measured and evaluated+- Involve the business operations team in determining what metrics to track and how they are tracked+- Work with engineers to add the required eventLog tracking+- Tools+    - Looker+    - Google analytics++### Refinement++- Designers will review metrics and determine if their designs are meeting objectives set for them.+- If areas for improvement are found, tickets will be created to document the change required to improve the issue  +### Final review of implementation +- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.

Thanks @rrhyne!

christinaforney

comment created time in 18 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com++### Pre-Launch+**User Testing** +- Hallway test with internal users.+- Open the feature to internal users by turning it on for the Sourcegraph organization. Make sure it's opened with enough+time left before planned launch date to receive and address all the feedback received.  Go to [our Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature only for internal users in the Sourcegraph organization.++**Design** +(skip if it doesn't apply)+- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.+* Test on small, medium, large and extra-large screen sizes.+  * Small screens are important to consider for a good experience when the window is resized or in side-by-side mode.+* Code examples in design+  * Font should be "code font" or monospace.+  * Easy to copy and paste (no fancy quotes).++**Analytics** +- Add and test logging for critical flows.++**Approvals**+- Receive approval from engineering, design, data, product and other stakeholders before launch. ++**Bug Tracking**+- Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.+- Track all lower priority bugs that have to be fixed soon.

Link to updated final design review in PR: https://github.com/sourcegraph/about/pull/1225

poojaj-tech

comment created time in 19 days

PR opened sourcegraph/about

Formatting and adding final review section

Review with "ignore whitespace" on, so you can more clearly see the change.

+127 -109

0 comment

1 changed file

pr created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com++### Pre-Launch+**User Testing** +- Hallway test with internal users.+- Open the feature to internal users by turning it on for the Sourcegraph organization. Make sure it's opened with enough+time left before planned launch date to receive and address all the feedback received.  Go to [our Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature only for internal users in the Sourcegraph organization.++**Design** +(skip if it doesn't apply)+- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.+* Test on small, medium, large and extra-large screen sizes.+  * Small screens are important to consider for a good experience when the window is resized or in side-by-side mode.+* Code examples in design+  * Font should be "code font" or monospace.+  * Easy to copy and paste (no fancy quotes).++**Analytics** +- Add and test logging for critical flows.++**Approvals**+- Receive approval from engineering, design, data, product and other stakeholders before launch. ++**Bug Tracking**+- Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.+- Track all lower priority bugs that have to be fixed soon.++### Deployment+**Push to Sourcegraph.com**+- Follow the steps in this [document](https://about.sourcegraph.com/handbook/engineering/distribution/update_sourcegraph_website) to enable your feature in global settings and to push it to all users on Sourcegraph.com.+- In the PR that pushes changes live, add everyone who gave appproval for launch as reviewers.++**Metrics**+- Share analytics for monitoring the feature shipped. Track metrics for regressions. ++### Post-Launch+**Marketing**+- Share update with marketing.++## TODO: Enterprise instances of Sourcegraph.com
## Sourcegraph Server

New versions of Sourcegraph are [released monthly](../engineering/releases.md#releases-are-monthly) to bundle changes for customers running Sourcegraph Server for their organizations. It is important that any new functionality has been thoroughly tested before including a feature on by default as part of a release. 

By following the above rollout process on Sourcegraph Cloud, we ensure that features included in a release are ready for use by customers.
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com++### Pre-Launch+**User Testing** +- Hallway test with internal users.+- Open the feature to internal users by turning it on for the Sourcegraph organization. Make sure it's opened with enough+time left before planned launch date to receive and address all the feedback received.  Go to [our Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature only for internal users in the Sourcegraph organization.++**Design** +(skip if it doesn't apply)+- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.+* Test on small, medium, large and extra-large screen sizes.+  * Small screens are important to consider for a good experience when the window is resized or in side-by-side mode.+* Code examples in design+  * Font should be "code font" or monospace.+  * Easy to copy and paste (no fancy quotes).++**Analytics** +- Add and test logging for critical flows.++**Approvals**+- Receive approval from engineering, design, data, product and other stakeholders before launch. ++**Bug Tracking**+- Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.+- Track all lower priority bugs that have to be fixed soon.++### Deployment+**Push to Sourcegraph.com**+- Follow the steps in this [document](https://about.sourcegraph.com/handbook/engineering/distribution/update_sourcegraph_website) to enable your feature in global settings and to push it to all users on Sourcegraph.com.+- In the PR that pushes changes live, add everyone who gave appproval for launch as reviewers.++**Metrics**+- Share analytics for monitoring the feature shipped. Track metrics for regressions. ++### Post-Launch+**Marketing**+- Share update with marketing.
### Post-Launch

1. **Marketing:** Share update with marketing.
1. **Metrics:** continue to track metrics to ensure expected outcomes are achieved.
1. **Enable by default:** Once a feature has been validated on Sourcegraph Cloud it can be enabled by default to be included in the next release. The feature flag should be left in place for at least one release cycle so that customers can disable the feature if problems arise.
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process

Use sentence case per https://about.sourcegraph.com/handbook/communication/style_guide#sentence-case

# Feature rollout process
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com++### Pre-Launch+**User Testing** +- Hallway test with internal users.+- Open the feature to internal users by turning it on for the Sourcegraph organization. Make sure it's opened with enough+time left before planned launch date to receive and address all the feedback received.  Go to [our Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature only for internal users in the Sourcegraph organization.++**Design** +(skip if it doesn't apply)+- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.+* Test on small, medium, large and extra-large screen sizes.+  * Small screens are important to consider for a good experience when the window is resized or in side-by-side mode.+* Code examples in design+  * Font should be "code font" or monospace.+  * Easy to copy and paste (no fancy quotes).++**Analytics** +- Add and test logging for critical flows.++**Approvals**+- Receive approval from engineering, design, data, product and other stakeholders before launch. ++**Bug Tracking**+- Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.+- Track all lower priority bugs that have to be fixed soon.++### Deployment+**Push to Sourcegraph.com**+- Follow the steps in this [document](https://about.sourcegraph.com/handbook/engineering/distribution/update_sourcegraph_website) to enable your feature in global settings and to push it to all users on Sourcegraph.com.+- In the PR that pushes changes live, add everyone who gave appproval for launch as reviewers.++**Metrics**+- Share analytics for monitoring the feature shipped. Track metrics for regressions. 
### Launch

1. **Enable for all to Sourcegraph Cloud users**
   - Follow the steps in this [document](https://about.sourcegraph.com/handbook/engineering/distribution/update_sourcegraph_website) to enable your feature in global settings and to push it to all users on Sourcegraph.com.
   - In the PR that pushes changes live, add everyone who gave appproval for launch as reviewers.
1. **Metrics**
   - Share analytics for monitoring the feature shipped. Track metrics for regressions. 
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com++### Pre-Launch+**User Testing** +- Hallway test with internal users.+- Open the feature to internal users by turning it on for the Sourcegraph organization. Make sure it's opened with enough+time left before planned launch date to receive and address all the feedback received.  Go to [our Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature only for internal users in the Sourcegraph organization.++**Design** +(skip if it doesn't apply)+- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.+* Test on small, medium, large and extra-large screen sizes.+  * Small screens are important to consider for a good experience when the window is resized or in side-by-side mode.+* Code examples in design+  * Font should be "code font" or monospace.+  * Easy to copy and paste (no fancy quotes).++**Analytics** +- Add and test logging for critical flows.++**Approvals**+- Receive approval from engineering, design, data, product and other stakeholders before launch. ++**Bug Tracking**+- Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.+- Track all lower priority bugs that have to be fixed soon.
### Before merge

- Run hallway tests with internal users
- Complete a final [design review](design/design_process.md#final-review)
- Review documentation
- Review analytics and ensure desired metrics have been added to the feature
- Confirm feature flag functionality

### After merge, before launch

1. **Gather internal feedback:** Enable the feature flag in the [Sourcegraph organization settings](https://sourcegraph.com/organizations/sourcegraph/settings) to enable your feature for all Sourcegraph team members. Be sure to leave enough time for folks to experience the feature in their workflows and provide feedback.
1. **Analytics:** Validate logging is working for critical flows
1. **Approvals:** Recieve approval from key stakeholders.
1. **Bug Tracking:** Keep track of all feedback.
   - Track and ensure high priority bugs in GitHub issues. Ensure they are closed before launch.
   - Track all lower priority bugs that have to be fixed soon.
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.
Features come in many different sizes and shapes, and the process for introducing new functionality ranges with these differences. For large or significantly impactful changes or changes that simply need a bit more time to bake, it is encouraged that the following rollout process is followed.
poojaj-tech

comment created time in 19 days

Pull request review commentsourcegraph/about

Add Rollout Process

+# Rollout Process++The rollout process consists of *Pre-Launch* phase and *Deployment* phase. We can push changes to Sourcegraph.com when we+want as we own the deployment process. For enterprise instances of Sourcegraph.com, we push a new release monthly and our+clients decide to upgrade to the latest release when they want.++## Sourcegraph.com
## Sourcegraph Cloud

Sourcegraph Cloud is continuously deployed with all new updates to master. We maintain a [releasability contract](../engineering/continuous_releasability.md) and require all new features to be released behind a feature flag to ensure that functionality can be turned off if a problem arises.
poojaj-tech

comment created time in 19 days

create barnchsourcegraph/about

branch : cf/design-final-review

created branch time in 19 days

push eventsourcegraph/about

Chayim

commit sha e95f43555eeb727caeb87537882003c450e7ea8f

Update index.md Fixing my own description and location.

view details

davejrt

commit sha e167fd6678492b86f4644a25fd34cd6c350714b0

add instructions on how to scale k8s cluster (#1168)

view details

Rob Rhyne

commit sha 6b8a94957b371f2e1a5a046f2aec1506ea95f4ce

Add responsive note (#1167)

view details

Stephen Gutekanst

commit sha 30144b6885aa890fb9663ca6f0bd302805937640

Update documentation about using metrics dumps (#1169) * Update documentation about using metrics dumps * Delete use_metrics_dump.md * Create metrics_dumps.md * Update index.md * Update metrics_dumps.md

view details

Quinn Slack

commit sha 11804d5d41e0723189397f60030e84f0d1c803c7

New design (#1101) * remove unused gophercon header styles * fix Props name * wip * wip * wip * wip * wip * wip * wip * WIP, make index (homepage) show more dev value props and features * wip * Update key landing page with minimal style changes * Added styles for darkbackground by: - adding sourcegraph-reverse-logo - updating to changes in header and fook - updating podcast pages * Make style updates on product and ucs page - Fix hero background - Update content page headings * Add H1 for pricing page Fix hero gradient on UCS pages * Update blog header todo: consider removing logomark in header * Add search illustration as a design comp * Let's fix the header. Also updated news hero * Add TODOs for header * Updated code search illustration * Navbar fixes - navbar-toggler-icon now displays for light and dark backgrounds - navbar background does not change for scroll down on podcast page - expanded view of navbar links in mobileview are now properly aligned * Pages updated - remove ebook on UCS page and product - fix hero on contact page - remove extra hr in pricing cards - cleanup minimal styles on contact pages * Add Try Sourcegraph component - updated home, customer, ucs page, and product pages Fix hover color on Get started button in nav * Fix hover color on nav button only Replace integrations nav link * Add copy text feature * First pass at customers content with videos, quotes, and screenshots Update nav * Updates to case study pages - Update nav, footer, and hero background color for case studies - Minor copy change on request a demo section * Fix button alignment for mobile * update web copy (#1144) * Update index.tsx * Update index.tsx * update copy * Update customers.tsx * Update index.tsx * Update website/src/pages/customers.tsx Co-authored-by: aileenrose <aileenrose@users.noreply.github.com> * Update index.tsx Co-authored-by: aileenrose <aileenrose@users.noreply.github.com> * Fix anchor locations Adjust spacing between sections Align logo in footer * Replace with new integrations section Fix wrap of deployment options Update font styles * copy updates + new graphics (#1149) * adding in videos to customers page * updating header * add videos to homepage * Update customers.tsx * Update CustomerLogosSection.tsx * Update index.tsx * Update index.tsx * adding in links questions link to mailto:feedback@sourcegraph.com --> future idea: could link to creating issue in GitHub but might not be good for folks not using GitHub other links to docs * fix video formatting and update case study text * Update customers.tsx * Update customers.tsx * Update integrations to no color * Home - fixed alignment of videos Customers - updated style on block quote and fix video caption Pricing - removed additional action boxes Footer - updated links Get started and request info - text updates * Add copy to clipboard icon and update link for 'want help' * Make textarea selectable and move copy icon inside too * Punchlist of style and mobile fixes, plus link updates - Home: order video after content on mobile - Customers: move logo below quote text - fix hero gradient to include nav - Shrink Uber logo - Pricing: update hero - Footer: on mobile, show logo at bottom - Nav: add border and place inside container - CaseStudy pages: update demo request section * Minor style edits to news, about, and jobs * Fix top of page padding on form pages * updating copy with additional edits (#1156) * Update index.tsx * updating customers page - including universal code search snippet - moving onboarding as first use case - copy edits * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update customers.tsx * Update index.tsx * copy edits * copy edits * - Logo updated with slight kerning for readability in mobile - Remove top gap on customers page * more web edits (#1163) * Update CustomerLogosSection.tsx * Update IntegrationsSection.tsx * Update index.tsx * Update TrySourcegraph.tsx * Update customers.tsx * Update index.tsx * Update Handbook logo Update blog post header to fit style * Update cookiebot style with theme color and updated font * Add redirects for deprecated pages and fix style on term pages * Setup og image for home, review first on staging * Update og images for new pages * - Alphabetize footer - Update to Sourcegraph strategy - Update hero style on contact and cookie policy pages * - Fix width issues of heading over logos - Fix width issues with Try Sourcegraph sections - Increased mobile width for post content - Added border bottom for menu expanded in mobile * Review of mobile vertical spacing * Update styles with new logo and fonts * - Add new logos - Fix spacing around the quantcast logo * Update title * Spacing with more logos * Update request demo Co-authored-by: aileenrose <aileenrose@users.noreply.github.com> Co-authored-by: adam <41576481+adaaaam@users.noreply.github.com>

view details

Rijnard van Tonder

commit sha 316d1e74c9d18afbf0354cb3e76f888c49e4095e

Broken link to metrics_dumpS.md (#1170)

view details

aileenrose

commit sha 14ce1719ce81e64cb7572d2097bbbc7fe29e451f

Update plan to strategy (#1171) quick update

view details

aileenrose

commit sha 4b597d4069ded5f4826ca80593d53b403afc03ab

Update meta tags on home (#1176) * Update plan to strategy * Set up meta tags including twitter image * Twitter not picking up helmet image * Reorganized and added meta tags

view details

renovate[bot]

commit sha 9dc0eb1a9e97cab010644b6703c218edea776a41

Update dependency @types/react to v16.9.42 (#1138) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha dc1f43b66c10af530a9758d1ec0e1547d928cc40

Update dependency @types/lodash to v4.14.157 (#1137) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

aileenrose

commit sha 9876b09ffc7e516a2fce6733d37ce3642bdd5978

Fix spacing and wrapping on pricing (#1181) and add border bottom to navbar

view details

Eric Brody-Moore

commit sha 97ab7bcf550b3c630419e4a7972ae45d840e9837

Post to Lever if no debrief (#1183) Proposing the HM posts to Lever to close the loop for those who interviewed the candidate and to limit confusion about cancelled debriefs

view details

Laureen Hudson

commit sha c884f9072d4803bc8238c2139b77750357d59cba

minor edits to index.md and style-guide.md for the week of 6 July 2020 (#1186) Co-authored-by: LaureenH <laureen.hudson@braingu.com>

view details

AlicjaSuska

commit sha 83b72b6a134dae4d388a08bc3d55e3f3868134b2

Add Working with design files + heading update I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools. In addition, I've changed slightly the formatting of the 'Process segments' section - using headers for the main steps in the process increases the readability of this document. Please, share your feedback regarding both the content and the form :) Thank you!

view details

AlicjaSuska

commit sha 67a40e8da06ee9908752b57f6f37ae283a95bed3

Reversing the previous commit I've committed my proposed changes to the master by mistake. This commit reverses those changes to the previous state.

view details

AlicjaSuska

commit sha 8b76830d351a8cfd54a356ef2d1362db42ccae7b

Add Plugins and Project Tools (#1188)

view details

Beyang Liu

commit sha 80caf6e5b55953bfd5aba36e11a120b1a63a7d56

podcast: publish luke hoban

view details

Beyang Liu

commit sha f43c44a96cab6f84b3c417006fb085d0c52d25f5

podcast: yves and john v0

view details

davejrt

commit sha 869776906ea080d0c138d4b960176a4faccae334

adjust heading for pulumi section (#1189)

view details

Quinn Slack

commit sha 878b33811395da119a5e7f957377c14201882b08

company meeting introing a new person

view details

push time in 19 days

delete branch sourcegraph/about

delete branch : cf/product-docs-overhaul

delete time in 19 days

push eventsourcegraph/about

Christina Forney

commit sha c39f347832c6c0e946193d681140a431081309e6

Product docs overhaul and definition of Product documents (PD) (#1200)

view details

push time in 19 days

PR merged sourcegraph/about

Reviewers
Product docs overhaul and definition of Product documents (PD)

This PR overhauls the product docs:

  • Standardizes on team members and hiring status for PM and Design
  • Updates the top-level product page to encompass both product management and product design
  • Adds documentation of new product documents (PDs)
  • Creates a product process page (more coming soon in follow up PR)
+180 -59

0 comment

12 changed files

christinaforney

pr closed time in 19 days

push eventsourcegraph/about

Christina Forney

commit sha a2a482e0ac8214951318d03df2b1c75ff62f2496

Adding org chart link

view details

push time in 19 days

push eventsourcegraph/about

adam

commit sha 74e03f65c795fae6d0481b7da1bfa0b783641838

Create hiring-talent-sourcegraph-cloud.md (#1202)

view details

adam

commit sha f36b80e72ecd766fb7ae44bad1818fc21e7ffcf6

update with copy edits for momentum blog post

view details

adam

commit sha 8133673bfb15d93c97798dda046ab8c3b0a0f0e5

more copy edits to momentum post

view details

aileenrose

commit sha 119661ca4859dba029c8ca3124de834afcffcd19

Add latest news and secure cross-origin links (#1203)

view details

aileenrose

commit sha 133ae33fea6c3260f786f83547bb125ee8408761

Add canonical links to pages (#1180)

view details

Adam Harvey

commit sha c62f45ca846e6956ed1527f6b37553caef677b72

handbook: Percy account setup has changed (#1207)

view details

Nick Snyder

commit sha a872b9d216de518e1e9544a5ac3e22c5b8754616

fix formatting, add J. P.

view details

Nick Snyder

commit sha dc103695c47becc582561b40d4e0f2785339d4b4

delete link to old roadmap

view details

Quinn Slack

commit sha 310bf28d9f14e5e4489575950c71ce3e69d83e73

note about needing to apply docsite config updates (#1131)

view details

Beyang Liu

commit sha b083c02edd5b869f20a6c35dd5fa2017be7deafb

podcast: yves and john transcript

view details

Beyang Liu

commit sha 821736a303c146807ea896554cfd38192cbe11c3

podcast: use search params rather than hash (so you can link directly to trnascript)

view details

Chayim

commit sha 06f69de1eac6cdd65fd3df2a3ad7ff223497a905

Update code_reviews.md

view details

Quinn Slack

commit sha f438e8ddd665ca4763f963726b29a19313cbd4cc

Add automatically generated org chart (#1212) Co-authored-by: Dan Adler <dadlerj@users.noreply.github.com> Co-authored-by: Nick Snyder <nick@sourcegraph.com>

view details

aileenrose

commit sha de4f9b7fc809c5c33f9f00b7420208e6f2e9358a

Fix 'does not have any construct or call' JSX error on Helmet (#1204)

view details

Quinn Slack

commit sha 83c4c07297acc03f2e563648a760c6f68be110ed

add engineering section

view details

Quinn Slack

commit sha e1f4508ab08ac40fb2156154fe547f79389dc3f2

remove redundant eng teams list from eng index

view details

Quinn Slack

commit sha 5d3d22d9c1d420d1bcb47729ebd04222e9d02213

other structure

view details

Quinn Slack

commit sha 74a2d6225757044beaf1c6eea25acba61277b579

link to top of page

view details

Ryan Blunden

commit sha 4fac44788daf67a432a207beb226873298c4a0a1

Update Sourcegraph version to 3.17.3 (#1214)

view details

Chayim

commit sha 27f7811a18ffbc9960e8029ba5a23b522bc3e938

Updating security team members

view details

push time in 19 days

push eventsourcegraph/about

Christina Forney

commit sha a57d3167ccfd9963a7f577614a7d0ad80257dea7

Updating for org chart format, updating PD based on feedback

view details

push time in 19 days

Pull request review commentsourcegraph/about

Goals (not OKRs): continuous, fewer in number, less strict format

+# Goals++Our company goals are public:++- [New *continuously updated* goals starting as of FY20-Q3 (upcoming, not publicly visible yet, will be moved to handbook soon)](https://docs.google.com/document/d/1Z6avFUmnGW-ZC6zrktqqQd_g5mhBE96C_mTwXwFc1H4/edit#)+- Historical snapshots:+  - [FY20-Q2 (active)](2020_q2.md)+  - [FY20-Q1](2020_q1.md)+  - [CY19-Q4](2019_q4.md)+  - [CY19-Q3](2019_q3.md)++## Philosophy++We believe:++- "Plans are useless, but planning is essential."+- "No plan survives first contact with the customer."+- "A plan is only useful for determining the immediate next thing to do. Beyond that, you must be ready to abandon the plan in the face of new evidence."+- Discarding a goal that turns out to be wrong is better than following through on the wrong goal. People know this intellectually but disregard it in practice.+- Each problem we're solving has a different (and often unknown/unknowable) timeline and rate of progress.+- Only people with skin in the game can set useful goals.++## Goals are continuous, not quarterly++1. Goals are continuously updated, and each goal specifies its own time period. They are not (for example) quarterly.+   - No single update/review cadence (such as quarterly) makes sense for all goals.+1. Change your goal immediately if/when you discover it's the wrong goal.+   - Reflect on why you needed to change the goal (so you can learn), but don't keep working toward the wrong goal.++## Choosing goals++A goal's format is:++> **Goal title** \+> Description of the goal and how to evaluate whether we met the goal (with a link to an automatically updated metrics dashboard, if appropriate).++1. Each goal has a single person (not multiple people) who's ultimately responsible for it.+   - Many people can be working toward a goal, but there must be one person who's ultimately responsible.+1. No person can have more than 7 goals at once. (This number is arbitrary, but it feels right.) Fewer is better.+1. Pick goals where failure would be painful.+1. Pick goals where you can influence the outcome. Avoid using a lagging indicator as a goal.+1. For a new project, it can be hard to define the right goal and measurement. Do your best. Then refine the goal as you learn more.+1. Set goals to be ambitious but achievable, so that they convey your aims and what you could achieve if things go well.+   - In (rough) numeric terms, if you achieve less than 70% of your goal, it was probably not achievable. If you regularly achieve 100%+ of your goals, they are probably not ambitious enough.

Since these goals are continuous, I would expect that we're working towards 100% on each goal (presuming this goal is still important and has not been invalidated).

Another concern/question - it feels likely that we will start to reach 70% on a goal, declare it good enough and move on to a new goal. Perhaps that is ok, but would indicate that goals are too hard, when in fact we just chose "good enough" and the true goal was actually appropriate.

sqs

comment created time in 19 days

Pull request review commentsourcegraph/about

Goals (not OKRs): continuous, fewer in number, less strict format

+# Goals++Our company goals are public:++- [New *continuously updated* goals starting as of FY20-Q3 (upcoming, not publicly visible yet, will be moved to handbook soon)](https://docs.google.com/document/d/1Z6avFUmnGW-ZC6zrktqqQd_g5mhBE96C_mTwXwFc1H4/edit#)+- Historical snapshots:+  - [FY20-Q2 (active)](2020_q2.md)+  - [FY20-Q1](2020_q1.md)+  - [CY19-Q4](2019_q4.md)+  - [CY19-Q3](2019_q3.md)++## Philosophy++We believe:++- "Plans are useless, but planning is essential."+- "No plan survives first contact with the customer."+- "A plan is only useful for determining the immediate next thing to do. Beyond that, you must be ready to abandon the plan in the face of new evidence."+- Discarding a goal that turns out to be wrong is better than following through on the wrong goal. People know this intellectually but disregard it in practice.+- Each problem we're solving has a different (and often unknown/unknowable) timeline and rate of progress.+- Only people with skin in the game can set useful goals.++## Goals are continuous, not quarterly++1. Goals are continuously updated, and each goal specifies its own time period. They are not (for example) quarterly.+   - No single update/review cadence (such as quarterly) makes sense for all goals.+1. Change your goal immediately if/when you discover it's the wrong goal.+   - Reflect on why you needed to change the goal (so you can learn), but don't keep working toward the wrong goal.++## Choosing goals++A goal's format is:++> **Goal title** \+> Description of the goal and how to evaluate whether we met the goal (with a link to an automatically updated metrics dashboard, if appropriate).++1. Each goal has a single person (not multiple people) who's ultimately responsible for it.+   - Many people can be working toward a goal, but there must be one person who's ultimately responsible.+1. No person can have more than 7 goals at once. (This number is arbitrary, but it feels right.) Fewer is better.

I think 7 is a lot, I would feel more comfortable with 5 as the max. This also aligns with our desire to be more focused as an organization because it makes us choose what is most important.

1. No person can have more than 5 goals at once. (This number is arbitrary, but it feels right.) Fewer is better.
sqs

comment created time in 19 days

Pull request review commentsourcegraph/about

Goals (not OKRs): continuous, fewer in number, less strict format

+# Goals++Our company goals are public:++- [New *continuously updated* goals starting as of FY20-Q3 (upcoming, not publicly visible yet, will be moved to handbook soon)](https://docs.google.com/document/d/1Z6avFUmnGW-ZC6zrktqqQd_g5mhBE96C_mTwXwFc1H4/edit#)+- Historical snapshots:+  - [FY20-Q2 (active)](2020_q2.md)+  - [FY20-Q1](2020_q1.md)+  - [CY19-Q4](2019_q4.md)+  - [CY19-Q3](2019_q3.md)++## Philosophy++We believe:++- "Plans are useless, but planning is essential."+- "No plan survives first contact with the customer."+- "A plan is only useful for determining the immediate next thing to do. Beyond that, you must be ready to abandon the plan in the face of new evidence."+- Discarding a goal that turns out to be wrong is better than following through on the wrong goal. People know this intellectually but disregard it in practice.+- Each problem we're solving has a different (and often unknown/unknowable) timeline and rate of progress.+- Only people with skin in the game can set useful goals.++## Goals are continuous, not quarterly++1. Goals are continuously updated, and each goal specifies its own time period. They are not (for example) quarterly.+   - No single update/review cadence (such as quarterly) makes sense for all goals.+1. Change your goal immediately if/when you discover it's the wrong goal.+   - Reflect on why you needed to change the goal (so you can learn), but don't keep working toward the wrong goal.++## Choosing goals++A goal's format is:++> **Goal title** \+> Description of the goal and how to evaluate whether we met the goal (with a link to an automatically updated metrics dashboard, if appropriate).

In support of the first item below, should the person responsible be listed by the goal?

> **Goal title** \
> Owner: the name of the single person who is responsible. 
> Description of the goal and how to evaluate whether we met the goal (with a link to an automatically updated metrics dashboard, if appropriate).
sqs

comment created time in 19 days

PR closed sourcegraph/sourcegraph

Reviewers
Fix file header text wrapping on long paths on Bitbucket bitbucket browser-extension

Fix #11110

Summary of attempts to solve this issue:

  • Didn't find a way to keep using display flex while making the file path wrap
  • No clear solution to wrap both file path and toolbar buttons: because they're on the same line, the desired wrapping behavior isn't obvious
  • Simplest apparent solution: remove flex and use aui-buttons class which already exists and is used on Bitbucket toolbar buttons.

Limitations of this solution:

  • Toolbar buttons don't wrap if there's an excessive number of them. The file path (sharing space with the buttons) will wrap instead.
+7 -25

8 comments

2 changed files

marekweb

pr closed time in 19 days

pull request commentsourcegraph/sourcegraph

Fix file header text wrapping on long paths on Bitbucket

Closing as Merek notes in previous comment.

marekweb

comment created time in 19 days

Pull request review commentsourcegraph/code-intel-extensions

hover source code intel tooltips

+import * as sourcegraph from 'sourcegraph'++export const HoverAlerts = {+    LSIF: <sourcegraph.Badged<sourcegraph.HoverAlert>[]>[+        {+            summary: {+                kind: sourcegraph.MarkupKind.Markdown,+                value:+                    'Semantic result. [Learn more.](https://docs.sourcegraph.com/user/code_intelligence/lsif)',

Agree, and I remember that thread. This seems like the best we have for now!

gbrik

comment created time in 19 days

Pull request review commentsourcegraph/code-intel-extensions

hover source code intel tooltips

+import * as sourcegraph from 'sourcegraph'++export const HoverAlerts = {+    LSIF: <sourcegraph.Badged<sourcegraph.HoverAlert>[]>[+        {+            summary: {+                kind: sourcegraph.MarkupKind.Markdown,+                value:+                    'Semantic result. [Learn more.](https://docs.sourcegraph.com/user/code_intelligence/lsif)',+            },+            badge: {+                kind: 'info',+                hoverMessage:+                    "This hover text comes from a pre-computed semantic index of this project's source. Click to learn how to add this capability to all of your projects!",

@LaureenH - the reason I made alternate suggestions is that "text" feels inaccurate to me. This is because it'ts not just copy. It's information about your code including the function definition, parameters and types, as well as any available documentation in the code. Here's what it looks like: image

gbrik

comment created time in 20 days

Pull request review commentsourcegraph/code-intel-extensions

hover source code intel tooltips

+import * as sourcegraph from 'sourcegraph'++export const HoverAlerts = {+    LSIF: <sourcegraph.Badged<sourcegraph.HoverAlert>[]>[+        {+            summary: {+                kind: sourcegraph.MarkupKind.Markdown,+                value:+                    'Semantic result. [Learn more.](https://docs.sourcegraph.com/user/code_intelligence/lsif)',

In context on the hover I think these make sense, but reading them here I'm wondering if we could be more clear what this means. Not everyone will understand what a language server is, what semantic means in this context, etc. I know some of this will be clarified in the hover info, but am curious to briefly discuss.

gbrik

comment created time in 20 days

Pull request review commentsourcegraph/code-intel-extensions

hover source code intel tooltips

+import * as sourcegraph from 'sourcegraph'++export const HoverAlerts = {+    LSIF: <sourcegraph.Badged<sourcegraph.HoverAlert>[]>[+        {+            summary: {+                kind: sourcegraph.MarkupKind.Markdown,+                value:+                    'Semantic result. [Learn more.](https://docs.sourcegraph.com/user/code_intelligence/lsif)',+            },+            badge: {+                kind: 'info',+                hoverMessage:+                    "This hover text comes from a pre-computed semantic index of this project's source. Click to learn how to add this capability to all of your projects!",

'hover text' may not be clear or accurate. Alternative ideas:

  • "This code intelligence data"
  • "This hover data"
  • "This reference data"

We have some style guide info on wording of links, though this is a bit difference since it's in a hover: https://about.sourcegraph.com/handbook/communication/style_guide#links

gbrik

comment created time in 20 days

Pull request review commentsourcegraph/sourcegraph

Add extension API for hover alerts

 export class HoverOverlay<A extends string> extends React.PureComponent<HoverOve                         // and communicate to the user we couldn't find a hover.                         <em>No hover information available.</em>                     ) : (-                        hoverOrError?.contents.map((content, index) => {-                            if (content.kind === 'markdown') {-                                try {-                                    return (-                                        <React.Fragment key={index}>-                                            {index !== 0 && <hr />}+                                    hoverOrError?.contents.map((content, index) => {+                                        if (content.kind === 'markdown') {+                                            try {+                                                return (+                                                    <React.Fragment key={index}>+                                                        {index !== 0 && <hr />} -                                            {content.badge && this.state.showBadges && (-                                                <BadgeAttachment-                                                    className="hover-overlay__badge e2e-hover-badge"-                                                    iconClassName={this.props.iconClassName}-                                                    iconButtonClassName={this.props.iconButtonClassName}-                                                    attachment={content.badge}-                                                    isLightTheme={this.props.isLightTheme}-                                                />-                                            )}+                                                        {content.badge && this.state.showBadges && (+                                                            <BadgeAttachment+                                                                className="hover-overlay__badge e2e-hover-badge"+                                                                iconClassName={this.props.iconClassName}+                                                                iconButtonClassName={this.props.iconButtonClassName}+                                                                attachment={content.badge}+                                                                isLightTheme={this.props.isLightTheme}+                                                            />+                                                        )} -                                            <span-                                                className="hover-overlay__content e2e-tooltip-content"-                                                dangerouslySetInnerHTML={{-                                                    __html: renderMarkdown(content.value),-                                                }}-                                            />-                                        </React.Fragment>-                                    )-                                } catch (error) {-                                    return (-                                        <div className={classNames(this.props.errorAlertClassName)} key={index}>-                                            {upperFirst(asError(error).message)}-                                        </div>-                                    )-                                }-                            }-                            return (-                                <span className="hover-overlay__content" key={index}>-                                    {content.value}-                                </span>-                            )-                        })-                    )}+                                                        <span+                                                            className="hover-overlay__content e2e-tooltip-content"+                                                            dangerouslySetInnerHTML={{+                                                                __html: renderMarkdown(content.value),+                                                            }}+                                                        />+                                                    </React.Fragment>+                                                )+                                            } catch (error) {+                                                return (+                                                    <div className={classNames(this.props.errorAlertClassName)} key={index}>+                                                        {upperFirst(asError(error).message)}+                                                    </div>+                                                )+                                            }+                                        }+                                        return (+                                            <span className="hover-overlay__content" key={index}>+                                                {content.value}+                                            </span>+                                        )+                                    })+                                )}                 </div>                 {hoverOrError && hoverOrError !== LOADING && !isErrorLike(hoverOrError) && hoverOrError.alerts && (                     <div className="hover-overlay__alerts">-                        {hoverOrError.alerts.map(({ content, type }) => (-                            <div-                                className={classNames('hover-overlay__alert', this.props.infoAlertClassName)}-                                key={type}-                            >-                                <div className="hover-overlay__alert-content">-                                    <small>{content}</small>-                                    <a-                                        className="hover-overlay__alert-close"-                                        href=""-                                        onClick={this.onAlertDismissedCallback(type)}-                                    >-                                        <small>Dismiss</small>-                                    </a>+                        {hoverOrError.alerts.map(({ summary, badge, dismissalType }, index) => (+                            <div className="hover-overlay__alert-container" key={index}>+                                <div+                                    className={classNames('hover-overlay__alert', this.props.infoAlertClassName)}+                                >+                                    {badge && !dismissalType &&+                                        <BadgeAttachment+                                            className="hover-overlay__badge e2e-hover-badge"+                                            iconClassName={this.props.iconClassName}+                                            iconButtonClassName={this.props.iconButtonClassName}+                                            attachment={badge}+                                            isLightTheme={this.props.isLightTheme}+                                        />+                                    }++                                    <span+                                        className="hover-overlay__content"+                                        dangerouslySetInnerHTML={{ __html: summary.kind === 'plaintext' ? summary.value : renderMarkdown(summary.value) }}+                                    />++                                    {badge && dismissalType &&+                                        <BadgeAttachment+                                            className="hover-overlay__badge e2e-hover-badge"+                                            iconClassName={this.props.iconClassName}+                                            iconButtonClassName={this.props.iconButtonClassName}+                                            attachment={badge}+                                            isLightTheme={this.props.isLightTheme}+                                        />+                                    }

cc @rrhyne to add consult design perspective in on Felix's suggestion.

gbrik

comment created time in 20 days

push eventsourcegraph/about

Christina Forney

commit sha c3a5898ab89a7599b02bcba3dcc5b2c9c972d841

Apply suggestions from code review Co-authored-by: Nick Snyder <nick@sourcegraph.com>

view details

push time in 21 days

Pull request review commentsourcegraph/about

Product docs overhaul and definition of Product documents (PD)

+# Product documents++A Product Document (PD)'s purpose is to communicate the high level product problem that needs to be solved. It is the one place where ongoing research and information can be aggregated around a particular problem statement. Product documents exist to encourage quick iteration, the ability to fail fast, and multiple efforts to be combined towards a singular problem statement.++These documents were created out of a need to orient around a particular problem statement, and the realization that it sometimes takes multiple [RFCs](../communication/rfcs.md) to fully solve a problem. This helps to aggregate the motivations and learnings around a problem, so that individual RFCs can focus on a particular proposed solution.++_All PDs are in a [public Google Drive folder](https://drive.google.com/drive/folders/1Wd-Xx2wNbFtSzeJwbZqMOxdbFDUFxlyR)._++## PDs have similar properties to RFCs++They are:++- [Sequentially numbered](../communication/rfcs.md#rfcs-are-sequentially-numbered)+- [Google Docs](../communication/rfcs.md#rfcs-are-google-docs)+- [Public](../communication/rfcs.md#rfcs-are-public)+- [Open to external contributions](../communication/rfcs.md#external-contributors)++## Status++Each PD has a status that is in the title of the PD (e.g. "PD 1 WIP: Title"). The author is responsible for keeping the status updated.++| Status | Description |+|-------|-------------|+| WIP | The author is still drafting the PD and it is not ready for review. |+| REVIEW | The PD is ready to be reviewed. The PD explicitly lists whose approvals are required and a requested timeline for those approvals. |

Good catch - I started to clarify this in the language I have below about metadata, but missed it here.

christinaforney

comment created time in 21 days

Pull request review commentsourcegraph/about

Product docs overhaul and definition of Product documents (PD)

+# Product documents++A Product Document (PD)'s purpose is to communicate the high level product problem that needs to be solved. It is the one place where ongoing research and information can be aggregated around a particular problem statement. Product documents exist to encourage quick iteration, the ability to fail fast, and multiple efforts to be combined towards a singular problem statement.++These documents were created out of a need to orient around a particular problem statement, and the realization that it sometimes takes multiple [RFCs](../communication/rfcs.md) to fully solve a problem. This helps to aggregate the motivations and learnings around a problem, so that individual RFCs can focus on a particular proposed solution.++_All PDs are in a [public Google Drive folder](https://drive.google.com/drive/folders/1Wd-Xx2wNbFtSzeJwbZqMOxdbFDUFxlyR)._++## PDs have similar properties to RFCs++They are:++- [Sequentially numbered](../communication/rfcs.md#rfcs-are-sequentially-numbered)+- [Google Docs](../communication/rfcs.md#rfcs-are-google-docs)+- [Public](../communication/rfcs.md#rfcs-are-public)+- [Open to external contributions](../communication/rfcs.md#external-contributors)++## Status++Each PD has a status that is in the title of the PD (e.g. "PD 1 WIP: Title"). The author is responsible for keeping the status updated.++| Status | Description |+|-------|-------------|+| WIP | The author is still drafting the PD and it is not ready for review. |+| REVIEW | The PD is ready to be reviewed. The PD explicitly lists whose approvals are required and a requested timeline for those approvals. |+| DEFINED | The problem statement defined and agreed upon, and is locked to changes. This is to ensure that anyone involved in solving the problem statement defined within the PD does not need to worry about changing scope. A change to the problem statement likely requires a new PD to be created to define the new problem statement. If the update is minor enough, all interested parties should be notified. |+| ABANDONED | There are no plans to move forward with solving the problem statement defined in the PD. The particular reason is communicated in the metadata section of the PD. For example, the PD may have failed to get the necessary approvals, it may be been superseded by another PD, priorities may have changed, or we may not have resources to work on this PD in the foreseeable future. |+| SOLVED | The problem statement defined in the PD has been solved. |++## PD structure++Effective PDs contain the following information. The below might feel like a heavy structure, this is intentional to help ensure all important considerations and context has been written down. Many sub-sections are very short, and some can be omitted if not relevant to the specific PD.++_For convenience, there is a [Google Docs Template](https://docs.google.com/document/d/1MBZxnRlDG69Fyvzpai5rBqxizvX5zVeZiUe6z7VZrjk/edit?usp=sharing) that can be used when creating new PDs. The template format should help clarify the below structure._++- Title that includes the PD number.+  - The title is inlined in the Google Doc so that it is more visible and will not disappear if exported to a different format.+- Metadata about the state of the PD. Including but not limited to:+  - **Editor:** The person responsible for iterating on the content of the RFC.+  - **Status:** A description of the current state or outcome of the PD.+  - **Requested approvers:** The list of people that the PD author is requesting a review from and a requested deadline for those reviews.+  - **Approved by:** A list of people who approve the problem statement defined in the PD.

I will clarify. What I want to achieve from approvals is:

The member of the team (likely design/engineering/other PMs) agrees that the problem statement is valid, and has enough context to begin solving the problem (whether or not it is actually prioritized or when they start the work is a different aspect). They are agreeing that what has been laid out by product is enough of a baseline to begin/move out of WIP/Review states. This is also why there is not an approved state, but a "Defined" state - meaning that the problem statement should not be modified.

christinaforney

comment created time in 21 days

Pull request review commentsourcegraph/about

Product docs overhaul and definition of Product documents (PD)

+# Product documents++A Product Document (PD)'s purpose is to communicate the high level product problem that needs to be solved. It is the one place where ongoing research and information can be aggregated around a particular problem statement. Product documents exist to encourage quick iteration, the ability to fail fast, and multiple efforts to be combined towards a singular problem statement.++These documents were created out of a need to orient around a particular problem statement, and the realization that it sometimes takes multiple [RFCs](../communication/rfcs.md) to fully solve a problem. This helps to aggregate the motivations and learnings around a problem, so that individual RFCs can focus on a particular proposed solution.++_All PDs are in a [public Google Drive folder](https://drive.google.com/drive/folders/1Wd-Xx2wNbFtSzeJwbZqMOxdbFDUFxlyR)._++## PDs have similar properties to RFCs++They are:++- [Sequentially numbered](../communication/rfcs.md#rfcs-are-sequentially-numbered)+- [Google Docs](../communication/rfcs.md#rfcs-are-google-docs)+- [Public](../communication/rfcs.md#rfcs-are-public)+- [Open to external contributions](../communication/rfcs.md#external-contributors)++## Status++Each PD has a status that is in the title of the PD (e.g. "PD 1 WIP: Title"). The author is responsible for keeping the status updated.++| Status | Description |+|-------|-------------|+| WIP | The author is still drafting the PD and it is not ready for review. |+| REVIEW | The PD is ready to be reviewed. The PD explicitly lists whose approvals are required and a requested timeline for those approvals. |+| DEFINED | The problem statement defined and agreed upon, and is locked to changes. This is to ensure that anyone involved in solving the problem statement defined within the PD does not need to worry about changing scope. A change to the problem statement likely requires a new PD to be created to define the new problem statement. If the update is minor enough, all interested parties should be notified. |+| ABANDONED | There are no plans to move forward with solving the problem statement defined in the PD. The particular reason is communicated in the metadata section of the PD. For example, the PD may have failed to get the necessary approvals, it may be been superseded by another PD, priorities may have changed, or we may not have resources to work on this PD in the foreseeable future. |+| SOLVED | The problem statement defined in the PD has been solved. |++## PD structure++Effective PDs contain the following information. The below might feel like a heavy structure, this is intentional to help ensure all important considerations and context has been written down. Many sub-sections are very short, and some can be omitted if not relevant to the specific PD.++_For convenience, there is a [Google Docs Template](https://docs.google.com/document/d/1MBZxnRlDG69Fyvzpai5rBqxizvX5zVeZiUe6z7VZrjk/edit?usp=sharing) that can be used when creating new PDs. The template format should help clarify the below structure._

I was wondering about that too. Perhaps a more high level discussion of why each of the top sections is important and why we included them in the PD template would be more helpful here. Then the template becomes the source of truth for all the individual sections and descriptions/prompts.

christinaforney

comment created time in 21 days

push eventsourcegraph/about

Christina Forney

commit sha bad3bf47a76049f7e97c53f0fb227efacf94083a

Fixing roadmap link

view details

push time in 21 days

PR opened sourcegraph/about

WIP: Product docs overhaul

This PR overhauls the product docs:

  • Standardizes on team members and hiring status for PM and Design
  • Updates the top-level product page to encompass both product management and product design
  • Adds documentation of new product documents (PDs)
  • Creates a product process page (currently WIP, to be completed)
+195 -59

0 comment

11 changed files

pr created time in 21 days

push eventsourcegraph/about

Christina Forney

commit sha 364f87c6d8600652a3200592f855764e11d3bf65

Fixing broken links

view details

push time in 21 days

more