Core application team
While you could think this is an angry cloud, it’s actually a fierce and determined one 😃.
The core application team owns a number of fundamental areas in our product and code base.
Our current work-streams are:
- Core application: Building, securing and scaling our multi-tenant hosted version of Sourcegraph for customers that do not want to deploy Sourcegraph on-premise. Also meeting the needs of larger and larger enterprises to support those deals (e.g. Perforce support)
- Backend platform: Make it easy for teammates of different experience levels to onboard and contribute to backend code. Hide and remove non essential complexity from engineers working on new product features and use cases. Promote and champion consistency and simplicity across all backend code by building shared tools, libraries and infrastructure for common use cases. Scale and maintain said infrastructure. Create leverage for and accelerate other teams.
Areas of ownership
- Authorization and authentication
- Repository management (gitserver, repo-updater, src-expose)
- Data storage and access libraries
- GraphQL API
- License generation and enforcement
- Admin and user settings
#core-application channel or @core-app in Slack
team/core-application label in GitHub.
#backend-platform channel in Slack
team/backend-platform label in GitHub.
We have two week cycles 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 channel for daily updates.
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.