3 ms·

Why the need to reinvent the commit message? Look at how Linux does it. If it's good enough for a globally distributed organization creating the operating syste

Why the need to reinvent the commit message? Look at how Linux does it. If it's good enough for a globally distributed organization creating the operating system the cloud and most phones run on, it can't be completely wrong. They rely solely on mail and commit messages. Ticketing systems are useful for a lot of other things such as keeping track of work on an individual level, or managing project resource allocations on a company wide level, but I'm not sure it's the best tool to do audits and have accountability. It will at best be a secondary source of that data.

lifeisstillgood 3y ago
And the Linux mailing lists are a great example of what I mean - deciding what to do and why is a huge upfront discussion - one they do in the open. but it's a crap backwards looking method for a summary. Most businesses hide the upfront discussion (or at least keep it to a smaller set of people who have often conflicting incentives for decisions as well (we tend to refer to this as politics but that's a bit like fish moaning about water.) Anyway the point is that Linux shows how to make good decisions in the open (usually) - a process that I think most would 10x good decision making in most businesses but also lead to huge other sets of problems (worth it in my view but ...). But Linux does not have a simple way of post-hoc justifying the decisions unless one reads the threads (which is where the recent post of open source journalist at lwn was a great idea) But things like Jira, external ticket stores are good at providing a hierarchy to post hoc justify the decision - even if they are a terrible way to plan forwards. So the ideal I guess is some kind of open architecture discussion upfront and some kind of extract and rebuild the rationale from commits (ie in house journalism?)
- lifeisstillgood 3y ago
  This is more a note to self There are two kinds of "tickets" - forward looking ones that basically say "we have a problem, please analyse and solve it using software" and a second closely related type that is "we have found the solution to the problem, please apply the solution to our environment" this is basically the dividing line between dev and ops. and the confusion is what causes so many problems - there is development in support of R&D then there is development in support of ops one cannot be predicted or sensibly estimated. One can. Our plain comes frommmixing the two

lifeisstillgood 3y ago

And the Linux mailing lists are a great example of what I mean - deciding what to do and why is a huge upfront discussion - one they do in the open. but it's a crap backwards looking method for a summary. Most businesses hide the upfront discussion (or at least keep it to a smaller set of people who have often conflicting incentives for decisions as well (we tend to refer to this as politics but that's a bit like fish moaning about water.) Anyway the point is that Linux shows how to make good decisions in the open (usually) - a process that I think most would 10x good decision making in most businesses but also lead to huge other sets of problems (worth it in my view but ...). But Linux does not have a simple way of post-hoc justifying the decisions unless one reads the threads (which is where the recent post of open source journalist at lwn was a great idea) But things like Jira, external ticket stores are good at providing a hierarchy to post hoc justify the decision - even if they are a terrible way to plan forwards. So the ideal I guess is some kind of open architecture discussion upfront and some kind of extract and rebuild the rationale from commits (ie in house journalism?)

lifeisstillgood 3y ago
This is more a note to self There are two kinds of "tickets" - forward looking ones that basically say "we have a problem, please analyse and solve it using software" and a second closely related type that is "we have found the solution to the problem, please apply the solution to our environment" this is basically the dividing line between dev and ops. and the confusion is what causes so many problems - there is development in support of R&D then there is development in support of ops one cannot be predicted or sensibly estimated. One can. Our plain comes frommmixing the two