Skip to content
This repository has been archived by the owner on Jul 2, 2024. It is now read-only.

Commit

Permalink
Merge branch 'main' into rrhyne-patch-3
Browse files Browse the repository at this point in the history
  • Loading branch information
sourcegraph-bot authored Apr 15, 2024
2 parents 7266572 + c89e982 commit c58a228
Show file tree
Hide file tree
Showing 21 changed files with 348 additions and 51 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ The purpose of this policy is to define the acceptable use of Sourcegraph’s In

## Background

While Sourcegraph’s resources are intended to be used for business purposes, users are allowed to make limited personal use of computers and email provided that such use does not negatively impact the organization. Such use is subject to this and all other organization security policies.
While Sourcegraph’s resources are intended to be used for business purposes, users are allowed to make limited personal use of computers provided that such use does not negatively impact the organization. Such use is subject to this and all other organization security policies.

## Scope

Expand All @@ -17,7 +17,7 @@ This policy applies to all Sourcegraph employees and contractors (referred to in
# Policy

Sourcegraph’s resources are intended for legitimate business purposes.
Sourcegraph employees may make reasonable limited personal use of the organization's IT resources such as laptop and email provided that such use does not negatively impact the organization or interfere with their duties.
Sourcegraph users may make reasonable limited personal use of the organization's IT resources such as laptop and email provided that such use does not negatively impact the organization or interfere with their duties.
Sourcegraph’s email accounts are the property of the organization and should be used for business purposes only. Users should send and receive personal email from a personal account.
Users assume personal responsibility for appropriate use of such resources and agree to comply with this policy, other applicable policies, and all applicable laws and regulations.
Our aim is to ensure IT resources are available and used for productive business purposes. To ensure our IT resources are used appropriately, safe and stable, users are prohibited from engaging in any activity with IT resources that may jeopardize or are contrary to appropriate use. In particular, the transmittal, retrieval, or storage of information that is inappropriate for the workplace is not permitted while at work or with organization resources. Prohibited use includes, but is not limited to, content that violates any law, involves nudity, violence, illegal drugs, sex, or gambling, or involves discriminatory, harassing, disturbing, obscene or pornographic material. In addition to these guidelines, users should use common sense and consideration for others in deciding which content is appropriate for the workplace.
Expand Down
6 changes: 4 additions & 2 deletions content/departments/cloud/technical-docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,9 @@ The release process is performed in steps:
1. New version is released via [release team](../../engineering/teams/release/team/index.md)
2. GitHub issue in [Sourcegraph Customer repository](https://github.com/sourcegraph/customer) with the `mi2 env create-tracking-issue -e prod $TARGET_VERSION` command
3. GitHub issue is labeled with `team/cloud` and Cloud Team is automatically notified to perform Managed Instances upgrade. Label is part of the template.
4. Cloud team performs upgrade of all instances in given order:
4. Cloud team performs upgrade of all instances in given order depending on the release type:

#### Release process for quarterly major release

| Stage | Working days since release | Action | Condition not met? |
| ----- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
Expand All @@ -34,7 +36,7 @@ Sample upgrade:
- [tracking issue - 5.1.4](https://github.com/sourcegraph/customer/issues/2251).
- GitHub Pull Requests for [5.1.4 upgrade](https://github.com/sourcegraph/cloud/pulls?q=is%3Apr+is%3Aclosed+label%3Ami-upgrade+5.1.4)

#### Release process for patch releases
#### Release process for monthly minor or patch releases

With [bi-weekly patch release schedule](../../engineering/dev/process/releases/index.md#patch-schedule), Cloud Team is using simplified release process to ensure Cloud customers can obtain patch as soon as possible.

Expand Down
237 changes: 237 additions & 0 deletions content/departments/engineering/linear-trial.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,237 @@
# Using Linear at Sourcegraph (trial)

<!--
TODOs post adoption:
- Remove trial from doc title
- Combine with 'working with issues' doc
- Update guidance around label groups.
- Update mentions of Eng Private team if we
merge that with main Eng team. Maybe we still need
a separate OSS team for OSS repos.
-->

This document describes recommended ways of using Linear
during the trial period, without causing a disruption to
team members who continue using GitHub
and are not part of the trial.

While the [Linear docs](https://linear.app/docs) are excellent,
here is a very quick run down of the core mental model.

- The workspace is divided into Teams.
- Settings related to workflow (issue statuses, estimates, cycles),
templates (for issues, projects etc.), syncing with external tools
and so on are customizable per Team.
- **Issues** are the smallest unit of work.
- Issues can have sub-issues, be blocked by other issues etc.
- An Issue belongs to a single Team: the issue identifier includes
a short prefix based on the Team. (Example: ENG-123)
- **Views** allow slicing/dicing Issues in flexible ways.
- Views work both within Teams and across Teams.
- **Projects** allow grouping issues into more coherent units.
- A Project belongs to a single Team, but can contain issues
that belong to other Teams.
- Project can have Documents that allow inline comment threads
similar to Google Docs.
- **Roadmaps** allow grouping projects into larger units,
and are owned at the workspace level.

For more details, see the [conceptual model docs](https://linear.app/docs/conceptual-model).

## Logging in

Install the [Linear app](https://linear.app/download) or
go to [our Linear workspace](https://linear.app/sourcegraph)
and log in with SAML SSO.

## Team structure

For now, we will aim to use coarse-grained teams.
To start out with, there are 5 teams: Eng PUBLIC,
Eng Private, Product, Design and Implementation.

Teammates in other parts of the company interested
in testing out Linear should feel free to create new Teams.

### Eng PUBLIC and Eng Private

Eng PUBLIC has _full_ bidirectional syncing with `sourcegraph/sourcegraph`.
This means that the following will be synced across,
regardless of whether the change is made in Linear or GitHub:

1. New issues being created.
2. Changes to labels, issue title, issue description,
new comments (for the "GitHub thread" in Linear), and
open/close status.

All other repositories have _partial_ bidirectional syncing,
which means that out of (1) and (2) above, only (2) is enabled,
i.e. new issues created in Linear will not be synced to GitHub.
This applies to:

- `sourcegraph/customer` - synced with Eng Private
- `sourcegraph/cody`
- `sourcegraph/src-cli`
- `sourcegraph/scip`, `sourcegraph/scip-java` and other indexers
- All other private repositories that have syncing turned on.
The full list of repos with syncing can be found [here](https://linear.app/sourcegraph/settings/integrations/github).

Both Eng PUBLIC and Eng Private are configured to use [2 week cycles](https://linear.app/docs/use-cycles)
based on [RFC 916](https://docs.google.com/document/d/16mipKz0fc2Ki5NYXG8Rarb8b4KHh34t27P9Ao_m8e-o/edit).

## Adding a new repository (for Engineering)

You can ask for help in `#wg-linear-trial` with these steps as well.

1. Add the repository to the [GitHub integration](https://linear.app/sourcegraph/settings/integrations/github).
If you do not see repositories in the Sourcegraph GitHub org listed here,
you may need to request the `sourcegraph - Owner` GitHub permission in Entitle.

- For private repos, use the `Eng Private` team.
- For public repos, use the `Eng PUBLIC` team.

DO NOT enable the "Enable bidirectional sync" toggle;
it only applies to _new issues_ created in Linear.
Comments, label changes, title and description changes will
still sync bidirectionally even if that toggle is disabled.
See the [FAQ](#faq) for more details.

2. Under [Import / Export](https://linear.app/sourcegraph/settings/import-export),
add a GitHub repository. After clicking 'Connect to GitHub' there may
be a delay of 10-15s before you see the options for selecting a repo.

If you do not see repositories in the Sourcegraph GitHub org listed here,
you may need to request the `sourcegraph - Owner` GitHub permission in Entitle.

- If present, disable the toggle for importing data from organization level projects.
- Enable the toggle for importing data from closed issues.
- Select the team to import issues into:
- For private repos, use the `Eng Private` team.
- For public repos, use the `Eng PUBLIC` team.

After importing is complete, you will have the option to configure it.
Make sure all these checkboxes are checked:

- Import N open issues
- Import N stale issues to Archive
- Import N closed or done issues to Archive
- Sync issues after import

So that syncing is maintained for old issues, and all issue history
is available for search.

After this step, select 'Import users' and make sure that:

- If a person has 'Map to Existing' but no associated account on
the right side, then change it to 'Do not create'
- Replace any 'Create with email' with 'Do not create'

Once you click next, confirm on the next page that:

- The number of user invites is zero
- The number of completed issues matches up with the closed
issues in the repo's GitHub issue tracker.

At the moment, all repos except for the monorepo use an extra issue label
to allow filtering for views inside Linear. For example, the `scip-java`
repo uses the `graph/scip-java` label.
Here is an [example PR](https://github.com/sourcegraph/scip-java/pull/685/files)
for auto-adding the label to new issues.
For old issues, you can quickly add the label after importing into Linear.

## Dos and Don'ts

1. **Don't create new Teams for sub-teams in Engineering**
(except for testing Linear features, that's OK).
Instead, let's try to tweak existing settings or enable new ones
which would be useful to all teams.
2. **Do add other repositories of interest to Linear**.
- Even for repos which only have PRs, if the PR descriptions
use Linear identifiers such as `Fixes ENG-123`,
then the corresponding issue will be auto-closed.
- Caveat: Do not enable bidirectional syncing for other repos
in Eng PUBLIC or Eng Private.
3. If your team is on-board, **do connect your team's #discuss
channel with Eng Private using Linear Asks**
([here](https://linear.app/sourcegraph/settings/asks))
to easily turn Slack threads into issues. ([docs](https://linear.app/docs/linear-asks))
4. **Avoid creating new label groups inside Linear**
(creating new labels, is OK). - If you attempt to create a new label with `/` on-the-fly
when editing an issue, Linear will create a label group
instead of a "flat" label.

For example, if you type `X/Y` for a new label, it will create
a group `X` with a label `Y` in that group. Since `X` is the
group name, the label synced to GitHub will be just `Y`.
This may be confusing to someone seeing the issue on GitHub
as the prefix is no longer available.

- Label groups also have at-most-one semantics - you can't apply
multiple labels from the same group to a single issue.
- Alternative: you can create a label with `/` from the Team's settings
([example link](https://linear.app/sourcegraph/settings/teams/ENG/labels)).

5. **Do explore the various Linear [features](https://linear.app/docs)
and [integrations](https://linear.app/sourcegraph/settings/integrations)**.

## FAQ

### Why are Eng PUBLIC and Eng Private separate?

The Eng Private team is present because of the following
considerations:

1. We have some private repositories on GitHub.
2. We'd like to use bidirectional syncing for the trial
period to avoid disrupting people not using Linear.
3. To test out whether Linear can work well as a single
pane of glass for issues, we need to sync issues from
our private repos into Linear.
4. The Linear -> GitHub sync direction uses the default
repo set in the GitHub integration, instead of offering
a repo picker.
5. The default repo for Eng PUBLIC is sourcegraph/sourcegraph
for ease of use.

The above factors create the risk of an information leak
if someone creates an issue in Linear with customer details.

Eng Private also provides a natural place to create issues
from Slack threads which may have customer details.

### Why not create separate Linear Teams for each sub-team in Engineering?

We initially considered doing this but decided against it
for the following reasons:

- It would create a proliferation of issue prefixes in identifiers,
making it harder to identify the top-level team based on the identifier.
- If there were any re-orgs in the future, having the issue identifiers
change to reflect new team names would be a disorienting experience,
especially for teammates outside Engineering.
- For teammates outside Engineering, it would be valuable to reduce
the number of potential places to file issues.

However, if the flexibility provided by the current team structure
is not enough, then we can consider creating smaller Teams in Linear
at the end of the trial (around mid May).

### Why don't we have full bidirectional syncing for all repos?

This limitation is present because Linear doesn't offer a repo picker
in the UI if bidirectional issue creation syncing is
enabled for more than 1 repo.

This means that even if we enabled
bidirectional syncing for say `sourcegraph/cody` with the Eng PUBLIC
Team, you couldn't actually create issues which sync to that repo directly
in the UI. To have that work, we'd have to create a separate Cody Team
in Linear with `sourcegraph/cody` being it's default bidirectional syncing repo.

However, that would defeat the above goal of avoiding creating
separate Linear Teams for each sub-team in Engineering.

## Known restrictions

- No custom fields for Issues.
- An issue can have at most one assignee (DRI model).
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,8 @@
<!--
Generated documentation; DO NOT EDIT. Regenerate using this command: 'sg msp operations generate-handbook-pages'
Last updated: 2024-04-08 10:19:19.786117 +0000 UTC
Generated from: https://github.com/sourcegraph/managed-services/tree/1d49a322f05521dba8109692c72c1a665a89c5a9
Last updated: 2024-04-12 12:41:21.95814 +0000 UTC
Generated from: https://github.com/sourcegraph/managed-services/tree/cc51eaa4e11a3146ae0a173cc2b80076466df8f7
-->

This document describes operational guidance for Build Tracker infrastructure.
Expand Down
Loading

0 comments on commit c58a228

Please sign in to comment.