Usage

Q: What are the key components of a good ticket?

• Title: Briefly describe the task.
• Details: Include goals, specifications, user stories, or steps to reproduce an issue. Ensure no implementation blockers for GitStart.
• Acceptance Criteria: Define what is the criteria for the PR(s) to be accepted and merged.
• Attachments: Provide screenshots, designs, or resources for context.

Q: What kind of tickets can I assign GitStart?

Tickets that can be delivered within a sprint, ideally no more than 5 days of implementation required. We’ll break down large and complex tickets into smaller executable chunks if required.

The tickets can span various use cases, from frontend to backend development, testing and coverage, to technical debt and bug fixes. You can find more detailed use cases on our website.

Q: What is an ideal workflow cadence with GitStart?

By default, we work with your team in bi-weekly sprints with the start and end date of a sprint that you specify.

You’ll be able to indicate the priority of a ticket as you hand off GitStart tickets through our dashboard.

• Urgent: Overrides all tasks, may disrupt sprint delivery.
• High: Must be completed this sprint.
• Medium: Work on after High priorities are done.
• Low: Only pick up if all other tasks are complete.

We’d also appreciate it if you could give a size for tickets assigned to GitStart using your team’s existing method of measurement (e.g., JIRA Storypoints, Linear Issue sizes).

Q: How do we stay on top of everything?

We’ll schedule two recurring meetings which we’ll come prepared:

1. A bi-weekly sprint grooming meeting led by the technical project manager
   1. Discuss updates and retrospective of the previous sprint
   2. Clarify and prioritize tickets for the upcoming sprint
2. A monthly review meeting led by the client experience manager
   1. Usage overview
   2. Relationship building
   3. Discuss strategy – How GitStart can help with your Engineering / Product OKRs and wider roadmap

Q: What to do if things didn’t go well from your perspective?

Please escalate any kind of feedback either via the shared Slack channel, or DM the client experience manager.

Early escalations help us manage damage control and conduct an investigation, which we’ll share with you afterward with insights for improvement.

Q: What do we need from you for our QA?

• Figma or equivalent Design:
  • Provide design guide outlying preference and patterns (e.g. pixel-perfect vs. reuse design system)
  • If possible, provide dev mode access to properly inspect margins, paddings and elements
• Devices: Provide explicitly the devices, resolutions & responsiveness requirements
• QA environment: Agree on a specific environment in which QA occurs. GitStart can also optionally maintain seeds over time
• Test case management: Shared environment for running manual and automated end-to-end tests on each PR and release

Q: How to create a good developer experience together?

We want to create a good developer experience on the sliced repositories for our developers and AI agents.

There are a few components of continually striving for a good DevEx:

1. Contribution Guide: We can help you maintain a single source of truth for how best to contribute to the repo outside of linting and formatting rules
   • Auto-formatting and linting: It’s very important to ensure that auto-formatting and linting rules are in place so that we can make the most of your reviews. If they don’t exist, we can create a ticket to put them in place.
2. Testing:
   1. Unit and component tests: GitStart will maintain a preset % of unit test coverage for all code shipped
   2. Integration and End-to-end tests: We have found that good coverage lends itself to better collaboration, we recommend that you utilize us to implement new frameworks or increase your coverage if necessary.
3. Reproducible Builds: Dockerized builds, which can be utilized by GitStart help us ensure that we can replicate the required environments
   1. Seeding data: Provide us with the seed data required, or we can create a script to seed data for us to test locally
   2. Staging data: Provide us the environment access with sufficient testing data

Q: How should I review GitStart PRs?

We measure PR review cycles internally and aim to reduce it. We’d appreciate the following:

• Exhaustive review: We ask that you perform exhaustive code and QA reviews. This ensures that we can keep review cycles to a minimum (we aim for less than 3).
• For follow-up scope: If you have follow-up work that increases the scope, create a new ticket/PR.