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 GitHub projects to track that work. We do a sync retrospective on Mondays, before planning, and a general team sync meeting every other Monday. We use Geekbot in the #core-application-sync channel for daily updates and weekly digests.
- 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.