My process for building a feature

I usually add a "research" label and use it for issues where I'm researching if an idea is good or not, and I try to apply "bug" or "enhancement" to everything, but I'm not very structured about it. And I use random colors because I'm too lazy to standardize those across repos!

I come from a background in education, and there's so much more to thinking through categorization and labeling systems than many people realize. The way we tag things has a significant impact on how we think about them. An efficient, well-thought-out tagging system leads us to work more efficiently without even knowing it. A technically correct but fundamentally weak tagging system can easily end up hurting the process, by hiding things that we assume would surface when needed.

I'm surprised GitHub hasn't done more with this.

Having something like this is useful for a team as it helps communicate where you are, what you're working on, and avoids butting heads over process differences being surprises. It can also help with onboarding as the steps are written out and can reduce back-and-forth and help focus on the issue (whether it's an enhancement or a problem).

I use my projects a lot, so most of my feature ideas come from scratching my own itches. A few come in as feature requests from other users.

Then I file everything as issues, and keep an eye out for things where I can think I can get a lot of value for the smallest possible amount of work.

I mostly work on things where I think I can get to a working version in less than a few hours. This keeps me engaged and churns our a lot of useful stuff, but it can get in the way of the longer projects that would add more value if could dedicate the time to them!

So I'm still very much trying to figure this out. The hardest problem in tech is picking the right thing to work on next.

It's a very impressive piece of software. If I wasn't so reliant on GitHub I'd probably try using it for a real project.