I would like to know who determines what is a bug and if there is an appeal process.
Are you talking about some particular issue that you believe has been set to incorrect resolution? Please mention it.
A bug in LibreOffice is most often when something doesn’t work as intended by feature implementer - so in those cases, the judgement requires understanding the intention, usually reading the source code. In that case, the decision is made by developers who are experts in the domain of the problem.
Or an intended behaviour may give unintended side effects; in this case, usually simply confirming the effects happening is enough to confirm it being a bug.
Or a feature implementation benefits some part of users, but creates difficulties for another part; in that case, a UX (user experience) team intervention is required to decide which should be the resolution.
And there are more cases; there isn’t an exhaustive list, and thete isn’t (and needn’t be) a formal process; no decision is set in stone, and any may be reviewed if appealing arguments are provided to relevant issue in bug tracker.
A bug in LibreOffice is most often when…
After re-reading this, I see that “most” is very subjective; please ignore that word, without which the rest should be correct imo.
Shouldn’t a bug be in “most” cases be convicted to be one by showing that the behaviour supposed to be a bug is in contradiction to a “normative statement by proper authority”. Implementer’s intentions may be doutable from the beginning / insufficiently checked by respective experts / misunderstood by authority having them checked / no longer remembered correctly / meanwhile abandoned in one or another way…
Of course, normative statements may also have their flaws and there must be a “legal” way to change them.
To avoid misunderstanding: The ODF specifications or any specifications on such a general level will in any case need to be completed by thousands of “decisions” to get the behaviour of a software sufficiently defined, Undocumented decisions, or those only deducible from the code let us end up with no clear distinction concerning the is-it-a-bug-question.
Until there’s a clear sign that current practice is insufficient to properly tell bugs from non-bugs, there is no need for any overly-formal process.