Content Platform Team

The Content Platform team (part of the Enablement org) creates, manages, and optimizes the content platforms that enable the success of Sourcegraph’s business objectives.

Members

Our Strategy

Mission & Vision

Responsibilities

The current existing content platforms include:

Contact

Requests

The content platform team helps with updates or changes to the various sites we are responsible for. Requests to the content platform team can be made through a Slack workflow:

  1. In the #content-platform channel in Slack, click the + icon, then “Content Platform Request”
  • Content platform request in Slack
  1. This will prompt you to fill out a form with relevant details.
  2. Completed forms will be sent to the content platform product manager, who will triage and update you with more information.

Principles

We inherit Sourcegraph’s engineering principles and practices and Enablement principles and practices.

Processes

Triaging Incoming Requests

The Content Platform Product Manager triages and prioritizes requests on a daily basis. They will:

  1. Verify all necessary information is in the request
  2. Determine urgency and priority against other work
  3. Set expectations with stakeholder/requester
  4. Create a Github issue (may automate this, TBD)
  5. If applicable, assign to a developer. Otherwise put into the team Kanban board according to priority determined in step 2.

Creating Issues

Prioritizing Issues

  • 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 weekly team sync to prepare for the upcoming week

Issue Status + Updating Issues

  • All work tracked in the Content Platform Github project
  • Views:
  • Statuses:
    • 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.
    • Not Doing/Cancelled: Issue has been resolved another way, meaning no work is needed on this issue. Or, we have decided not to work on this issue. Either way, the reason for moving to this status should be explained in a comment.
  • Automation:
    • When an issue or PR is added to the project, its status is set to Needs Triage.
    • When an issue or PR is reopened, its status is set to Needs Triage.
    • 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 a PR is merged, its status is changed to Done.

Planning

We plan using a Kanban workflow in a Github project. We do not work in iterations or sprints.

Weekly Planning Meeting

  • Overview: 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 status of inflight work and next priorities
  • When: Mondays at .

Retrospectives

  • 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 at .

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 against other work
  • All work follows a specific process created in collaboration with marketing.
    • Sharing the design with a developer step:
      • Developer will review design async and provide feedback on the feasibility of the design. They should always have access to all figma files and be notified of design changes that may increase the lead time.
        • Use PERT technique for estimation.
          • Estimation should include 3 days for QA to give plenty of time for feedback and corrections.
        • Fabiana will share with Mary when ready, who will assign a developer who is likely to work on the page or feature.
  • Marketing will continue to track work in Asana, while the Content Platform team is tracking work in Github. Details of how this will work:
    • Fabiana is responsible for keeping Asana up to date.
    • Mary is responsible for keeping Github up to date.
    • We are using a Github + Asana integration to link Github PRs in Asana
    • Content Platform Team provides updates to their work in Github, including but no limited to:
      • QA links
      • Questions for stakeholders
      • Progress updates as needed
    • Mary and Fabiana will be working closely to ensure relevant information is present in both Asana and Github as needed. At the beginning this will feel like duplication of work, but we want to start doing this manually while we figure out our way of working, instead of over-engineering up front. Will look into further automation/syncing options in the future as needed.