4 ms·

> Need to prepare a deck for a business review? Open an issue. Want to refresh our career ladders? Open an issue. Planning an offsite? You guessed it, open an i

> Need to prepare a deck for a business review? Open an issue. Want to refresh our career ladders? Open an issue. Planning an offsite? You guessed it, open an issue. As an engineer (not a manager!) who does a lot of non-engineering tasks: this kind of misses the point. Don't get me wrong - if creating a GitHub issue helps you keep track of things, great. But GitHub (and most other engineering tracking tools) are meant for relatively clearly defined tasks, and the input on those tasks come only from engineers. But a lot of times we deal with amorphous, poorly defined tasks that involve non-engineers. "Put it in GitHub" is solving the easy part of the problem. The hard part is identifying who are all your stakeholders, getting them onboard, and turning that task that is ill-defined into something well-defined.

randomdata 4y ago
> But GitHub (and most other engineering tracking tools) are meant for relatively clearly defined tasks I am not sure that's true. They are meant to avoid the need for status meetings by providing more realtime feedback of what is and isn't happening to other people who benefit from knowing where things are at. As long as all interested parties understand the overall intent of the ticket, to know what it being closed means, it doesn't have to be well defined. If what you want to accomplish is so abstract that you can't even reach a shared understanding with others, they won't need to keep track of your status in the first place (what would they be keeping track of?), so that case is moot.