How to determine a good maximum total attachment size for issue trackers

We're using J*** as issue tracker and have an external consultant company which is consulting our IT, amongst others about maximum total file attachment size per issue.

They came up with the value 20MB without even looking at the type of projects and data we're dealing with and for our purposes it seems way too small, even considering only the lower 80% of possible cases.

Many of our issues can only be investigated in the context of the data which causes them (admittedly for some parts because of the lack of extensive logs and proper crash dumps, but not many are actual crashes so the latter isn't much of a problem) and because it's about 3D models in various formats, these data can get very big very fast. All are encouraged to shrink the data as much as possible reducing the projects to a minimal reproducible sample but this is not always done.

The only other possibilities to handle the data is either not providing it and making problem solving way harder or storing it externally which would add the need to cross link issues and data and also is not a good UX as long as it isn't transparently integrated in the issue tracker.

I tried to google for articles, papers, best practices and others but could find anything which goes in depth.

What are best practices for total attachment size limits and how did people develop them?

submitted by /u/ridilculous
[link] [comments]

from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/l1ZGdza

Leave a comment

Design a site like this with WordPress.com
Get started
search previous next tag category expand menu location phone mail time cart zoom edit close