Skip to content

Latest commit

 

History

History
120 lines (76 loc) · 8.57 KB

index.md

File metadata and controls

120 lines (76 loc) · 8.57 KB

Code insights team

The code insights team is responsible for building and delivering code insights to engineering leaders, empowering data-driven decisions in engineering organizations.

Screenshot of a code insights dashboard with graphs

Members

Mission

To create a Sourcegraph code insights product that answers all your important high-level questions about what's in your code and how it's changing.

Vision

Sourcegraph users – especially those in leadership roles – create and monitor code insights to answer vital questions about their code, including:

  1. How their code is tracking against any migration, pattern, or code smell goals
  2. How their code is changing over time and what areas may need more or less developer attention
  3. Understanding their code's current and historical content, like its languages, libraries, and structure
  4. What patterns or outliers exist in their third party tools' data when viewed at a high level
  5. Any of the above questions, but also filtered by repository, engineering team, or other division

Responsibilities

The code insights team is responsible for all code insights features, both backend and frontend.

While code insights is in prototype stage, the code insights team is also responsible for all support.

What is code insights?

Code insights is the first feature in Sourcegraph that can tell you things about your code at a high level.

Code insights dashboards will answer questions like "How is a migration progressing?", "What areas of the code are most vulnerable to bugs?", and "How many developers are using a specific API?" Code insights will also incorporate third-party data like code coverage or static analysis metrics to deliver on the promise of aggregating everything you can know about your code.

Sourcegraph is in the unique position to give these insights because we have universal code search: to know anything about your code at a high level confidently means you must know everything about your code at a low level.

Code insights connects many features that Sourcegraph already has and builds on top of them. We go beyond single-step code intelligence and search to connect the full cycle of analyzing (code intelligence), monitoring (code insights), and actionably changing a codebase (batch changes).

Code insights is the first feature primarily built for non-search-based user personas (developers), instead focusing first on the needs of engineering directors and VPs.

For more information about code insights, see the original product document or this demo of a code insights prototype. Anyone on the Sourcegraph team can create your own insight using the quickstart guide, which is explicitly not in the Sourcegraph docs because code insights is undergoing rapid development and this setup will soon change.

Contact

Goals and roadmap

Goals and roadmap

Processes

We share the web org processes, plus the following for our team. We use our bi-weekly retrospective to identify any tweaks we should make that would improve our process.

Weekly Sync

The team holds weekly syncs.

The meeting notes of team syncs can be found in this doc.

Before team syncs, teammates and stakeholders should write down under "Agenda" in the meeting notes document anything that they'd like to bring up for discussion with the whole team. Attendees are encouraged to add comments on talking points asynchronously before the meeting too.

Planning and prioritization

We plan and track our day-to-day work on our Kanban board. Our current process is as follows:

  • Incoming tickets (e.g. from other teams) arrive in the Inbox column.
  • Work is scheduled by adding a card to the Planned column. This happens after talking through the next priorities in our weekly sync or raising something asynchronously in the #code-insights-chat Slack channel.
    • The Planned column is an ordered column, by priority. Priority is discussed on the team.
    • Work should not be moved into this column until it is ready for development.
    • Anything that needs design input gets the needs-design label and goes in the Needs design column.
  • When starting work, engineers pull cards from the Planned column and move it to the In Progress column.
  • There should never be more than a couple of cards in the In Progress column at the same time. If we paused work on something (e.g. because priorities changed), it should be moved back to Planned or Icebox as appropriate.
  • Things we triaged from the Inbox, but don't plan to work on, go into the Icebox.

Tracking Issues

The team makes use of tracking issues for tracking progress on the implementation of longer projects that need to be broken up into multiple issues. The teammates should ensure that a tracking issue is created when starting work on features that are expected to take longer than a few days (or require multiple PRs) to deliver.

Product Feedback

Specific product feedback about well-defined, small features can be found directly in the GitHub board. More general product feedback that applies to larger features, or that needs more research and planning to be actionable, is kept in Productboard.

Retrospectives

Every two weeks, we hold a review/retrospective meeting to reflect on the past two weeks. We use this meeting to:

  • Review the previous retro’s action items to ensure they get completed
  • Give Shoutouts! to teammates to show appreciation for something they did that we appreciated
  • Discuss things that went well in the past two weeks and that we should do more of / invest more into it
  • Discuss the things that could have gone better and what we can learn from it to improve
  • Talk about processes that we should revisit/refine/propose to improve our efficiency.

We capture and assign actions to individual teammates. Teammates should consider actions coming out of the retrospective as a very high priority.

Teammates contribute to the retrospective asynchronously during the iteration by adding their thoughts to our retrospective document. Teammates are highly encouraged to comment on points raised before the sync meeting in the document.

We rotate who leads the retrospective to allow all teammates an opportunity to lead the session. Teammates can find the rotation schedule at the top of the retrospective document.

Code reviews

The team follows the default code review guidelines with the following addition:

  1. If the author would like any of the requested reviewers to merge the PR after approval they add the label merge-on-any-approve
  2. If the author would like their PR to be merged once all of the requested reviewers have approved it they add the label merge-on-all-approve
  3. When there are only minor issues, reviewers are encouraged to give "approval with comments" and trust their teammates to address the comments without requiring a follow-up review.