It is generally speaking good practice to avoid or at least limit global namespace writes because they lead to hard to debug interactions with other addons (or sometimes even default UI code if they shadow a variable)

If they can't be outright avoided, using variable names that at least lessen the chance of collisions.
Wrapping variables into the private addon table passed to all addon files in a vararg by the client is a good option for example.

local addonName, addon = ...
addon.myVar1 = "whatever"
addon.myVar2 = {}
addon.myFunc = function(arg1)
end
-- etc

Anyway to get to the point this is an interesting addon but it's leaking a ton of globals and some of them with very generic or short names.

• i_adjust
• setGetDiff
• deepCopy
• notFreshInstance
• iname
• sets
• avg
• quota
• mi
• s
• i
• mage_groups
• mage
• priest_groups
• priest
• druid_groups
• druid
• All the utility function names from ZodsRaidAssign.lua:894 to ZodsRaidAssign.lua:988 (dump, shallowcopy, modulo, tablelen, tablefirstkey, splitmess, remaining, mysplit, dicestring, codesToValsArr)

The Lua math library does have a math.fmod method you don't need your own btw 😉
In any case if you need utility functions available throughout your addon Lua files use the local addonName, addon = ... construct at the top of the files and wrap the functions into the private addon table, for example addon.dicestring = function(str) --do my stuff end

• some_events
• f

Most of those do not need some complex rewrite (I'd still wrap the utility functions in the addon private table or at least prepend the addon name to their name so they're not as generic ZodsRaidAssign_dump instead of dump.
For the rest it seems to be a case of forgetting to declare them as local .

Hope it helps.

thanks a lot. I didn't expect the feedback. I'll get to refactoring.