Note: This page is a work in progress to represent an updated organizational structure to facilitate future growth.
While you could think this is an angry cloud, it’s actually a fierce and determined one 😃.
The Core Application team has broad area ownership within the Sourcegraph product delivery organization. We are responsible for code host connection and repository management, administration experience, licensing, finance and subscription management, authorization, authentication, and IAM. The team also owns other platform-level developer enablement themes.
- Please ask questions and submit requests for assistance via #core-application Slack channel
@core-appto mention the team in Slack
- Use team/core-application label to tag the team in GitHub.
- Requests for assistance from Customer Support and other teams are triaged, worked on, and resolved based on their priority level by a team member on operational rotation.
- See Core Application Support board for information about all tracked requests and their current status.
We have two week sprints starting on Wednesdays. We do a sync planning the day before (Tuesday) where we determine what each teammate works on. We use JIRA to track that work. We do a sync retrospective before the planning meeting, and have a general team sync meeting every other Monday. We use Geekbot in the #core-application-sync Slack channel for daily updates.
We are establishing the operational rotation to predictably deliver sprint goals and provide the necessary support to other teams.
If you need assistance with a task, let the team know in the #core-application-sync channel. You’ll find your peers are more than happy to act as a rubber duck and get you unblocked, or direct you to the right person(s) for further assistance.
See Tagging teammates below for more information.
Consider setting up regular office hours so that peers can reserve your time, while knowing that they won’t be disrupting your daily workflow.
- Post-merge feedback: It is important to make progress while getting feedback from other teammates in code reviews. On the one hand, the pull request author doesn’t have to be blocked by all reviewers who the author intends to get feedback from; on the other hand, reviewers can still focus on their work on hands and leave feedback at their convenience. The pull request author should use their best judgement to decide if a pull request should wait (for high-risk changes) or simply rely on post-merge feedback.
- Approve to unblock: When the reviewer thinks there are no obvious blockers and trusts the pull request author will take care of comments/questions/concerns (e.g. answer to questions, explain rationale, act on code suggestions) before merging the pull request.
- Request for changes: When the reviewer believes it is important to get another round of review from the person before merging the pull request. This situation often happens when there is a significant design change.
The team is currently experimenting with JIRA as our project tracker.
To track GitHub PRs automatically in JIRA, use the JIRA ticket number anywhere in the branch name. So for example, if the ticket number is
COREAPP-42 and you name your branch
the-answer-to-everything-COREAPP-42, the resulting PR from this branch will automatically be associated with the JIRA ticket.
Feel free to tag
@core-app on Slack or anyone directly as and when required. It is acceptable to tag people to get their attention. On the contrary it is also acceptable to turn off your notifications when you want to focus and do not want to be interrupted.