Thank you for sharing. Even thou I have a lot fewer projects and majority of my work happens on the projects of clients - I managed to take away some useful ideas and tips. Specifically using "issue" as a place where everything gets tied together and combining all aspects of a feature into a single main-branch commit is something I will try to do more from now on.
Since your workflow is so GitHub centered, one place that IMO could use more structuring is GitHub issue labels [1] [2] [3]. Defaults are quite ad-hoc, with color not really representing anything. And setting up new default labels for new projects can be automated with command line scripts.
Thank you for sharing these resources. One of my first steps on a new project that I'll work with on an extended basis is to add new labels, and delete the ugly default ones I won't use. I've never made time to articulate my frustrations with the default labels, but these articles do a great job of identifying the issues, and proposing practical solutions.
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.
Yeah I could definitely do a better job with my labels.
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 was hoping this would discuss how he chooses which features to build. Unfortunately, that is not what this is.
It is a description of a pretty rigorous development workflow, but I think it will mostly only be useful to people who want to contribute code to Simon's projects.
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.
An example of a well documented "here's roughly how I do it" post with some rational on how they documented and why they have a preference.
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've tried it out a little bit - turns out you can import an existing git repository into it and browse the results with Datasette, which is pretty fun!
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.
Since your workflow is so GitHub centered, one place that IMO could use more structuring is GitHub issue labels [1] [2] [3]. Defaults are quite ad-hoc, with color not really representing anything. And setting up new default labels for new projects can be automated with command line scripts.
[1] http://karolis.koncevicius.lt/posts/improving_github_issue_l...
[2] https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b...
[3] https://robinpowered.com/blog/best-practice-system-for-organ...