Hi everyone 👋,
Matic here! In this blog post, I would like to share my journey of creating LabelSync, what LabelSync is all about and well, what I've learned building it. I hope this post encourages you to push your project past the finish line, or that you learn something new about LabelSync and GitHub.
The big picture
LabelSync is a labels management tool. In particular, it helps you manage GitHub labels. Right now, you are probably thinking: "why would you want to build a whole application just to sync some labels?" Well, hear me out.
GitHub is becoming a fantastic collaboration platform. Many open-source projects use it to gain reputation, developers can learn by reading the source code of large scale projects; the list goes on. Where GitHub doesn't shine (yet) though is project organisation. Say you want to prioritise and organise your tasks. Sounds like a Trello or Asana task, right? Maybe even Notion. These are all fantastic tools - I'll get to that in a minute - but most importantly, you are decoupling your code from your tasks. Even more! You are giving up the fantastic markdown editor in issues and all the assignments and task management that GitHub already offers. What if you could take out the clunky parts of GitHub, and somehow make them work together as well as Trello or Asana?
That's where LabelSync comes into play. How? Well, GitHub already offers project-scoped kanban board. What many of you probably don't know is that it also lets you list all issues in your organisation, your account, or - to be honest - every code that you are working on, from the issues tab. (I'll add a link at the bottom so you may check it out.) Think of it as a kanban-ish board. It doesn't let you do much. You can, however, however, filter issues by labels.
Using LabelSync, you can then precisely specify the labels that you are going to use inside your entire organisation and let LabelSync manage them for you. The awesome part? You don't have to learn a single new thing - it is soo effortless. LabelSync lets you configure your labels using code. Not exactly; you might choose code, but you may also choose a more straightforward YAML configuration file. Every time you make a change to your configuration, LabelSync first reports the changes to your pull request, and only performs the sync after you committed them to the master branch. It also lets you rename old labels to new ones and even lets you unite multiple old labels into one. LabelSync keeps every issue aware of the change. This way, you can transfer your existing triaging structure into GitHub with minimal effort and persist the current state of your projects. It also helps you reduce substantial team costs since you are using it on an organisation instead of per team member.
On the other hand, you might still want to use your existing tools. If, for example, your team primarily consists of non-developers or your team isn't that familiar with GitHub, it may be better to keep your tasks in an external organisation tool. Moreover, you might not want to use LabelSync if your team heavily relies on the drag-and-drop features of the Kanban boards in existing platforms like Trello. Lastly, you might simply want to spend more on these tools.
To sum it up; I wanted to ship a fantastic early product. LabelSync lets you
- Effortlessly set up your task-organisation in GitHub,
- Might cut your monthly bill,
- Help you reduce the number of tools you use. Trust me, GitHub is fantastic, and it loves LabelSync!
Currently, that sums up to a fantastic early product. Before I ship a Kanban board, I want to explore more use cases of LabelSync and how you organise your tasks. Perhaps it's even better to keep configuration in Notion, or Kanban board nonetheless, or something third. Who knows? Because we are keeping all the data in GitHub, however, it's straightforward to extend the functionality further on.
On the other hand, you might want to stick with your existing tool if
- Your team consists primarily of non-developers or isn't familiar with GitHub,
- You 100% need that Kanban board drag-and-drop,
- You want to spend some more.
Demo Link
Link to Code
maticzav
/
label-sync
🏷 A delightful companion to manage Github Labels across multiple repositories.
Managing multiple repositories is hard. LabelSync helps you manage labels across your repository fleet.
Why LabelSync?
While working at Prisma, I discovered that many companies struggle with repository organisation. In particular, companies struggle with managing labels across multiple repositories in their organisation.
My vision is to develop the best in class software that would help companies triage issues and pull requests, and simplify the use of labels.
Features and Quirks of LabelSync
Label Sync helps you sync Github labels across multiple repositories:
-
🛰 Centralised management: Handle multiple repositories from a central configuration. -
👮 Restricts unconfigured labels: Prevent adding new labels that don't fit into your workflow. -
🐣 Aliases: Quickly rename old labels to a new label. -
🎢 Siblings: Create workflows with labels.
F.A.Q
Is LabelSync free?
LabelSync will remain free while in beta.
I have a problem but don't
…How I built it?
My stack consists of
- Prisma - a fantastic ORM tool that helps you access your database,
- Probot - a GitHub bot framework that lets me listen to events and respond to them,
-
Heroku - where I host all server code. Heroku lets you split your build into the build, push and run steps using
heroku.ymlfile (link below), and it works excellent with Prisma. There's this thing called Prisma Migrate that allows you to track database changes easily - the model in particular. Splitting the build into three steps allows you to build everything upfront in the CI, and only commit changes to the database right before your server starts. It's great. - I am using Stripe to process all of my payments. If you haven't tried Stripe yet, you definitely should. The development experience is fantastic.
Additional Thoughts / Feelings / Stories
Start small! As mentioned above, you should try to create a great skateboard first, and only then create a bike or even a scooter. There used to be an image floating around Twitter visually explaining the idea, but I couldn't find it. TLDR; Don't try to create a bike with only one wheel and missing bell. Remove the unnecessary parts - like the issues view in LabelSync's case - and focus on the core. You'll progress faster, and your product will look better.
Don't over-engineer. There's a great talk from the Elm community on that topic - "The Life of a File" - that very well wraps together how you should approach writing code (link below). LabelSync, for example, started as one file with thousands of lines of code. Only once the patterns started emerging, I began splitting code chunks. Be conservative of over separating your code because it usually ends up worse than it should. Go, check out that talk!
Additionally, the website started as a simple HTML file. No server-side rendering or React or anything at all. Pure HTML and CSS. Why is that important? Because it keeps the project going. It's far better to rethink certain parts once you've finished everything than to leave out some features.
The End
I hope you learned something new, and most of all, enjoyed the reading. Until next time! 🙌
Links
- Issues tab: https://github.com/issues
- Heroku YML: https://devcenter.heroku.com/articles/build-docker-images-heroku-yml
- The Life of a File: https://www.youtube.com/watch?v=XpDsk374LDE
Top comments (0)