Is GitHub a worthy alternative to JIRA?

Having recently joined Lightdash’s Engineering team I’ve experienced the exciting world of open-source.

‍

From the very first day, I felt welcomed into a team that values transparency above all else. As an open-source BI tool, Lightdash instils its open-source nature in the team, fostering an environment of collaboration and openness.

Having only used JIRA in the past, I wanted to share my experience with using GitHub as the primary issue-tracking tool within a fully-remote team.

‍

🏗️ Building in public helped me level up
‍

Unlike the standard project management tool setup, Lightdash does not use tools like JIRA. Everything is on GitHub. We use GitHub to plan, prioritise, and spec work. It wasn't until I joined Lightdash that I realized I wasn't using GitHub to its fullest potential. As the team prides itself on being autonomous and independent, I too wanted to showcase that I could build by myself initially. But a few questions came up:

• Where do I look for bugs?
• What are people working on?
• What are the main goals to achieve this month?

‍

Initially, navigating through the repo felt quite overwhelming, and I didn't know what I needed to do to open my first pull request. However, I quickly learned that: Issues are like Stories/Tasks, while milestones are our Epics. PRs should, by default, close(or related to) an Issue. Labels are relevant (is this a Frontend or Backend piece of work? Bug? or a Documentation Improvement?). I quickly discovered that I could align my ways of working with the teams by re-learning GitHub.

At first, the idea of working on an open-source project where my code would be available for anyone to see felt overwhelming. The thought of being judged and criticized by others made me hesitant to contribute. However, as I started to dip my toes in, I realized that the transparency that comes with open-source development was exactly what I needed to improve my skills. Knowing that my code was open to scrutiny made me more mindful of the quality of work that I produced. I became more meticulous, leading to better code.

‍

🧠 Multiple skillsets, all in one place

‍

Now that I gradually felt more comfortable with my day-to-day tasks as a builder, the next natural step was to see how Engineers interacted with Product and Design. In the past I’ve dealt with the following all in separate platforms:

• Design reviews
• User Testing Feedback
• Product Research
• Product Planning

‍

I wasn’t too bothered by it because that was my “normal”. I would ensure that the code reflected the changes and/or new work coming through and would then handle the communication with the appropriate stakeholders.

Coming to Lightdash and realising that Designers and Product not only share all the insights mentioned above on GitHub but also review PRs, was a fresh surprise! But this doesn’t go in only one direction. Engineers are expected to be product-sharp and also voice their opinions on Milestones, how they’re prioritised, and comment on User feedback - which leads to external contributors!

Naturally, I expected to see GH users contributing to the project, but it’s a different feeling when you’re on the other side. You get positively surprised when a builder shares their solution to a problem we haven’t caught, or prioritised yet - contributions to Lightdash empower us to be at our best, every day.

TLDR: Having one unified “window” where I can see everything from feature ideation to materialisation removes friction I hadn’t noticed before.

‍

💻 Less context switching, more developing

‍

Being a fully remote team requires a great deal of process-busting and refining to be our best selves at work. One of our core values is that “we bias towards impact”, done is often better than perfect. Being a small powerhouse requires special attention to the way we work and who we should reach out to get something out ASAP. For example, we:

• Encourage everyone to achieve SME status on a particular part of the business - decreasing the time of individual research and speeding up decision-making
• Deliver features in small iterations - smaller PRs usually mean quick reviews (iterating on proof of concepts rather than being 'handed' a fully specced and researched solution)
• Occasionally get together in person to work on big-picture goals - sync up on processes, what we should work next to make a bigger impact
• Have GitHub as our one-stop-shop for Product+Design+Engineering and user feedback

‍

Moreover, the buzz that comes from seeing users get excited about new features is immensely motivating and propelled us to find new ways to keep the momentum going - we pride ourselves on releasing at least one PR per day!

‍

Joining Lightdash’s Engineering team has allowed me to experience the exciting world of open-source but I was surprised to find they lived without JIRA!

‍

‍

⚡️Interested in joining Lightdash?
‍

Come be a part of a team that values impactful growth for modern Data Teams (see our Job Board here)