I am used to treating the issue tracker as a source of truth and an organisational memory. I use it to record what the issue is and what has been done towards resolving it. I consider this to be essential and basic to good software engineering (including agile development).
I am willing to consider the possibility that I am wrong however.
I am now part of a development team split over multiple sites in the world not all of whom speak the same language (a few do not share English as a common language and can only communicate via my team leader). To me this makes good use of the issue tracker even more important.
However, the other team (despite my protestations) regularly adds user stories which are just a single line. If I am lucky enough for there to be a description it is quite terse. The stories are typically closed and accepted with no commentary added at all. Sometimes there are sub-tasks that only have a title. The team leader has to accept tickets after the developer closes them (and is thus complicit). Some of these are small issues but others are huge like "evaluate orchestration methods" which has led to the use of Kubernetes.
I am not discouraged from using the ticket tracker how I want myself but I have no visibility of what others are doing. Granted, I don't often need to know unless I am working on a related issue (my point is kind of that I might need to in the future). It seems they prefer talking face to face or not at all. This is claimed to be 'agile'. The issue tracker is just an internal tool not directly connected to any incentives, perverse or otherwise.
Is there any sane world or process in which this makes sense? Some kind of ultra lean - less paper, less testing, just barely enough code, tick the box and ship it system that actually works (or appears to work from the perspective of management)?
Bonus points for good suggestions on how get developers and management on board with better process.
