Content Platform Team
The Content Platform team creates, manages, and optimizes the content platforms that enable the success of Sourcegraph’s business objectives.
- Steve Yegge, Product Manager
- Steve Yegge, Head of Engineering
- Thorsten Ball, Head of Source
- Indradhanush Gupta, Software Engineer, repo-management
- Milan Freml, Software Engineer, IAM
- Erzhan Torokulov, Software Engineer, IAM
- Alexander Ostrikov, Software Engineer, repo-management
- David Veszelovszki, Software Engineer, IAM
- Petri-Johan Last, Software Engineer, IAM
- Idan Varsano, Software Engineer, repo-management
- Naman Kumar, Software Engineer, IAM
- Cezary Bartoszuk, Software Engineer, repo-management
- Peter Guy, Software Engineer, repo-management
- Chris Pine, Engineering Manager, Code Insights
- Vova Kulikov, Software Engineer, Frontend
- Coury Clark, Software Engineer, Backend
- Chris Warwick, Software Engineer
- Becca Steinbrecher, Software Engineer
- Owen Convey, Engineering Manager, Code Exploration
- Tom Ross, Software Engineer
- Valery Bugakov, Software Engineer
- Philipp Spiess, Full-Stack Engineer
- Felix Kling, Software Engineer
- Taras Yemets, Software Engineer
- Laura Hacker, Software Engineer
- Chris Pine, Engineering Manager, Batch Changes
- Erik Seliger, Software Engineer
- Dave Try, Software Engineer
- Marek Zaluski, Software Engineer
- Manuel Ucles, Software Engineer
- Adeola Akinsiku, Software Engineer
- Kelli Rockwell, Software Engineer, Batch Changes
- JH Chabran, Software Engineer
- Bolaji Olajide, Full Stack Engineer - Batch Changes
- Sander Ginn, Software Engineer
- Randell Callahan, Software Engineer
- William Bezuidenhout, Software Engineer
- Kalan Chan, Software Engineer
- Owen Convey, Engineering Manager, Code Intelligence
- Eric Fritz, Software Engineer
- Noah Santschi-Cooney, Software Engineer
- Ólafur Páll Geirsson, Software Engineer, Code Intelligence
- TJ DeVries, Software Engineer
- Cesar Jimenez, Software Engineer on Code Intelligence
- Varun Gandhi, Software Engineer
- Dominic Cooney, Software Engineer
- Rok Novosel, Software Engineer
- Malo Marrec, Product Manager, Batch Changes
- Ryan Phillips, Product Manager
- Taylor Sperry, Product Manager, Frontend Platform
- Rafal Gajdulewicz, Engineering Manager, Cloud
- Joe Chen, Software Engineer
- Dax McDonald, Software Engineer
- Robert Lin, Software Engineer
- Filip Haftek, Software Engineer
- Daniel Dides, Software Engineer
- Michael Lin, Software Engineer
- John Wesonga, Technical Program Manager
- Erika Rice Scherpelz, Head of Search
- Keegan Carruthers-Smith, Software Engineer
- Geoffrey Gilmore, Software Engineer
- Stefan Hengl, Software Engineer
- Juliana Peña, Software Engineer
- Camden Cheek, Software Engineer
- Gary Lee, Software Engineer
- Julie Tibshirani, Software Engineer
- Thorsten Ball, Head of Source
The current existing content platforms include:
The Content Platform team has the following customers:
- Marketing department: The marketing, blog, and learn sites.
- Engineering department: The docs site.
- Sourcegraph employees: The handbook site.
We inherit Sourcegraph’s engineering principles and practices.
- Customer-first: we exist to enable our customers to succeed against their objectives.
- Empowerment: we build everything to empower the customer to be self-sufficient in managing the content.
- Forward-thinking: we execute on our customers’ requests, keeping the overall content ecosystem in mind to drive efficiency and re-use.
- Indexability: Search engines’ ability to index the content is not an afterthought and is key to success.
- High-quality: The content platforms are the face of Sourcegraph to the public, and given our developer-focused audience, only the highest quality of engineering will be acceptable.
Where we are now
We intend to form a self-sufficient engineering team with all the necessary cross-functional roles to deliver on the mission.
We envision driving two workstreams inside of the team, one focused on the more traditional markdown-driven content architecture (handbook, docs) and one around CMS-driven content (marketing, blog, learn). By looking at our platforms from a content-neutral way, we still believe there are many shared elements between all the sites and want to optimize for efficiency. Also, if/when needs of the handbook and docs sites diverge more drastically from the other sites to the point where it causes inefficiency in the team, we will treat it as a signal that it is time to evaluate whether to split the team.
This team will be successful if it can deliver on its customers’ needs to help them achieve their goals. Streamlining the prioritization and delivery of work while enabling self-service ability is essential. Ultimately, meeting the delivery commitments on time will determine the team’s success.
- #content-platform and @content-platform-team on Slack
The Content Platform team helps with updates or changes to the various sites we are responsible for. Note: that if you’re comfortable making changes to one of these sites, you don’t have to put in a request for the Content Platform team. We are happy to serve as a review on your PR, but no need to put in a request unless you need us to complete the work for you. Requests to the Content Platform team can be made through a Slack workflow:
- In the #content-platform channel in Slack, click the + icon, then “Content Platform Request”
- This will prompt you to fill out a form with relevant details.
- Completed forms will be sent to the Content Platform Product Manager, who will triage and update you with more information.
- Note: You’ll see a condensed version of your request appear in the #content-platform channel instead of the full text you entered. Your full request will be sent directly to the PM via Slackbot, and they will follow up with questions as needed.
Service level agreements (SLAs)
- Initial response: All requests will be (triaged)[#triaging-incoming-requests] within one business day.
- Urgent requests: If your request is urgent, flag it in the #content-platform channel or contact the Content Platform Product Manager directly so they can respond as soon as possible. Urgent requests are issues impacting customers’ ability to interact with our sites, issues blocking an essential part of a current marketing campaign, or potentially other requests defined on a case-by-case basis.
- Non-urgent requests will be resolved by a due date agreed upon by the team and the requestor as part of triage.
- Urgent requests will be worked until the issue is resolved or no longer in an urgent state.
Triaging Incoming Requests
The Content Platform Product Manager triages and prioritizes requests on a daily basis. They will:
- Verify all necessary information is in the request
- Determine urgency and priority against other work
- Set expectations with stakeholder/requester. The Content Platform team work in two-week sprints and will confirm what will be added to next or future sprint after the bi-weekly planning meeting.
- Create a GitHub issue (may automate this, TBD) and link the issue in the request thread in the #content-platform channel. You can see an example here.
- If this is a marketing request, add the
marketing-requestlabel to the GitHub issue.
- If applicable, assign to a developer. Otherwise put into the team Kanban board according to priority determined in step 2.
- Anyone can create an issue in the repos we work in:
- Note: After issues are created, they must be added to the Content Platform Work project to be prioritized
- Anyone can request help from the Content Platform team according to this process
- Issues are then triaged and added to the proper repo in GitHub (and to the Content Platform Work project)
- Anyone can create an issue directly in the project
- Issues are prioritized as they come in by the Content Platform Product Manager, with input from the rest of the team and stakeholders
- Priorities are reviewed in the bi-weekly team sync to prepare for the next sprint
Issue Status + Updating Issues
- All work tracked in the Content Platform GitHub project
- All Issues contains issues that fall under the responsibilities of the content platform team, regardless of repo or site.
- Handbook contains issues in the Handbook repo.
- About/Marketing Site contains issues in the About repo, excluding issues labeled “docs”, “docs-ux”, or “blog”.
- Blog contains issues labeled “blog”.
- Learn contains issues in the Learn repo.
- Backlog: Issue has not yet been triaged or is otherwise not ready to be worked.
- Ready for Development: Issue has been triaged and prioritized, and is ready to be worked.
- In Progress: Issue is actively being worked on.
- In Review: Issue is in review. This could be a PR review, QA, or stakeholder review.
- Blocked/Paused: Work is currently paused on this issue. If possible, please add details about why the issue is blocked or paused. If you’re blocked, tag your PM for help.
- Done: Work is complete, PR is merged (if applicable), and no further action is needed on this issue.
- Not Planned: Issue has been triaged, but not prioritized with current work. This may mean it will be prioritized in the future when it aligns with the roadmap.
GitHub Automation workflows are currently in Beta and we take advantage of the following features available to us:
- When an issue is added to the project, its status is set to Backlog.
- When an issue or PR is reopened, its status is set to Ready for Development.
- In some cases, PRs may be reopened but are not yet In Progress again. If , manually change the status.
- When an issue or PR is closed, its status is changed to Done.
- In some cases, Not Doing/Cancelled may be a more appropriate status. If so, manually change the status.
- When PR changes are requested, the status is set to In Progress.
- When a PR is approved, its status is changed to In Stakeholder Review.
- When a PR is merged, its status is changed to Done.
All PRs made by the Content Platform team go through a creation and QA process.
Authors for PRs should include:
- Context in the description on what the PR achieves. This includes which issues it refers to, if any, using closing keywords to automate issue closing.
- A list of tasks as a Test Plan that a reviewer should test to ensure the proposed changes work as intended.
- At least 1 reviewer to review, provide feedback if necessary, and approve, in order to increase code health and prevent accidental bugs and changes from being snuck in after an approval has been made.
- Setting yourself as the assignee to keep track of your work.
- Any relevant labels, including the required
- Tagging the Content Platform Work project and setting the apropriate status through the stages of work: In Progress and In Review, to keep everyone informed.
- Any relevant Milestones.
- Any optional comments to lines of code to point out specific context for reviewers.
The QA Process should go as follows:
- Create a draft PR if your PR is still work in progress (WIP).
- Assign a reviewer once your PR is ready to be reviewed and is no longer WIP.
- If there are changes requested, push your changes and resolve conversations as they are fixed. You can optionally leave conversations unresolved if more conversation is necessary.
- Once approved, the Author merges and the branch is automatically deleted.
We work in two-week sprints and we plan our sprints on a bi-weekly basis. A sprint starts on a Monday and ends on the Friday of the following week. You can view our Current Sprint on GitHub.
Bi-weekly Planning Meeting
- Overview: Bi-weekly call with all the teammates to plan the next sprint.
- Goal: Plan and estimate the issues for the next sprint based on priorities and define a sprint goal.
- When: Monday
Bi-weekly Sync Meeting
- Overview: Bi-weekly call with all the teammates to discuss the work in progress and review upcoming priorities. Opportunity to surface dependencies on each other and other sources.
- Goal: Connect as a team, ensure we are all clear on the status of inflight work and next priorities.
- When: Every second Monday
- Overview: We conduct a bi-weekly retrospective to celebrate wins and share feedback.
- Goal: To ensure we improve as a team to become more efficient and effective.
- When: Every second Thursday
Engaging with Other Teams
- See this section for making a request to the Content Platform team.
Collaborating with Marketing
- Marketing will submit requests as needed. They will then be triaged and prioritized based on urgency indicated from the requestor.
- Content Platform team requires assets to be approved before adding it to the sprint backlog.
- Figma file: this is always the source of truth for design and copy
- Marketing will continue to track work in Asana, while the Content Platform team is tracking work in GitHub. Details of how this will work:
- Marketing Project Manager is responsible for keeping Asana up to date.
- Content Platform Product Manager is responsible for keeping GitHub up to date.
- GitHub issue contains a link to the Asana card, and Asana card contains a link to GitHub issue.
- Content Platform team provides updates to their work in GitHub, including but no limited to:
- QA links
- Questions for stakeholders
- Progress updates as needed
- All marketing requests go through our Marketing QA process and inherit our Pull Requests process.