What to Expect During Your First Month
Like any new developers learning your codebase and preferences, it takes a bit of time for GitStart to get up to speed. But once we get over the initial steps together, we can start delivering high-quality pull requests quickly.
We are ready to go. Are you?
GitStart is ready to work as soon as you’re done setting up your repos. We can start working on your tickets as soon as possible, and our collaboration will be most productive if you already have a backlog of well-scoped tickets ready for us to work on.
We’ll no doubt questions as we go along, and we’ll be in touch with you to clarify any doubts we have.
Help us build product context
In the first month, we’re getting to know your product and codebase. Any chance you have to let us know about your product goes a long way in the early days: it helps us understand the context of the tickets and the impact of the work we’re doing, and it helps internal QA teams test the work we deliver.
However, after the first few batches of pull requests successfully shipped, you can reduce the amount of context embedded in the tickets.
Your code and design preferences matter
Are you a team that wants pixel-perfect implementations, code according to specific style guides or have a preference for certain libraries or patterns? Let us know!
We have systems in place to analyze your codebase and learn your preferences, but not everything can be inferred. The more you can tell us about your preferences, the better we can deliver what you want.
Feel free to share your code style guides, design systems, and any other resources that might be helpful.
“What should I assign?”
Great first issues
What’s a good place to start? Glad you asked. We’d love to start with issues that are not too hard, not too easy. We know that you want to see results quickly, and we want to deliver them. Not too hard, because we’re still getting to know your codebase and product. Not too easy, because we want to show you what we’re capable of.
Good first issues take less than five working days to complete, including our internal testing and providing you with proof that it works.
Some great examples:
- Well-scoped bug fixes with clear reproduction steps. These are great because they’re usually small and self-contained.
- Small tickets that are part of a larger feature. These are great because they give us a sense of the bigger picture.
- Updating or adding small features to existing components. These allow us to get familiar with your design system and codebase.
Not-so-great first issues
These are usually things that require GitStart to make product and technical assumptions or contain many moving parts and dependencies. Examples include:
- Setting up a new codebase or project. This can be a bit too much, as it requires us to clarify a lot of things with you instead of autonomously working on the code.
- Large features without Figma designs or clear acceptance criteria. We want to make sure we’re building what you want, and coding without a clear goal is not ideal.
- Tackling complex user permissions or security features. We want to make sure we understand your product before we start working on these.
- Dependency upgrades, such as upgrading from one version of React to another. There is a very high bandwidth of potential side effects that could occur from this type of work.
- Critical bug fixes or time-sensitive work. We need to be able to take our time, and we don’t want to frustrate you.
Not sure what to start with? We can help you identify good first issues.
As GitStart’s product knowledge increases, you can increase the complexity of tickets.
Our estimates may not be perfect
We try to be as accurate as possible with our estimates, but we will not be perfect.
Developers estimate using help from a machine-learning model that predicts cost based on historical data and is continuously learning from new tickets and PRs. Do not be surprised if our estimates are off by a bit in the first month and don’t be afraid to talk to us about them.
We will try to be as transparent as possible about this.
Tell us how we’re doing
Last but not least, we’re here to learn and improve. If you see something we can do better, please let us know. We’re always looking for ways to improve our processes and deliver better results.
We couldn’t do it without your feedback!