https://bugs.documentfoundation.org/show_bug.cgi?id=147004
--- Comment #19 from [email protected] --- (In reply to Heiko Tietze from comment #18) > any heading greater or equal the level (which is totally unexpected > do some modifications for the understanding now, > wouldn't wait for volunteers to pick up the implementation error. This situation raises a dilemma, which I do not know how to resolve. The horns of the dilemma - Make the UI/tooltip/help page correspond to: a. actual (current) behavior, or b. "intended" (?) behavior (i.e., "level" selects specified outline level) No strong opinion either way, but would prefer some decision/agreement about how to act in relation to the dilemma (in light of the actual situation). fwiw -- I would recommend a. (for reasons listed below). Better to make the UI and help reflect the current behavior (choice a.) -- but I believe that choice "breaks" with the general principle that I have learned from Mike, to document intended behavior (choice b.) -- hence the dilemma. Reasons for choice a. 1. if implementation is not likely to change (any time soon), then why invite (dupl) bug reports (such as this one), by following choice b? 2. for typical document structures (e.g., that start with outline level 1 heading, and where all the other heading paragraphs have an outline level that is -1, 0, +1 in relation to the headings before and after), then "actual" behavior is pretty close (approaching identical?) to the b. solution. 3. if there is no knowledge about the intended behavior (i.e., maybe the current behavior is not an implementation error?), and no strong use case argument for one kind of behavior vs. another (beyond what seems "logical"), then documenting a. makes it possible/meaningful (for someone else) to file a request to change the behavior, when a genuine use case arises. 4. A modest search attempt for BZ tickets about levels in relation to variables and captions gave no result => either the level control is not used much, or not problematic enough to motivate BZ tickets, or users (by trial and error) can get what they want. => if not broken, don't fix it? In sum, better to wait for a genuine use case (or knowledge of the intended design) that motivates changing current behavior to another, and to document the current behavior -- with an eye to typical use (where this ticket and bug 153560 provided more detailed documentation about current behavior). -- You are receiving this mail because: You are the assignee for the bug.
