https://bugs.documentfoundation.org/show_bug.cgi?id=169484

--- Comment #8 from Telesto <[email protected]> ---
(In reply to Eyal Rozenberg from comment #7)
> That's a good point regarding that mockup. But the UI change for support of
> Start and End should be mostly orthogonal. For example, in that mockup, we
> would need 6 options instead of 4 (or decide the UI doesn't expose Left and
> Right, only Start and End). And also, with our current Table properties
> dialog, we need to add options for Start and End.

True. However splitting it sometimes feels as waste of resources. Spending time
lots of time on dialog (discussion; code change, review and so) which in
advance being known to be out-dated. Obviously it's a balancing act. Bundling
not a panacea either:
* to much effort, so bug being avoided because of being to large
* to complex (or to many open ends regarding the implementation)

Doing less
* Incrementally means: only partial change; without another change for probably
year. Lots of half baked stuff

---Meandering thoughts --
Discussions about multitude of aspects within a single bug report quickly
resulting in a indecipherable mess. OTOH: having dozens of separated bugs which
- in the end - are actually heavily interconnected but presented totally
separated resulting in atomization/insight silo's. Meaning limited to no
integration of the subtopics & lack of general overview.

So at one hand I'm in favor in splitting discussion into dedicated bugs. OTOH I
prefer those to be grouped into overarching actionable bugs (which more or less
a conclusion/summary's off all the subtopics). This result in some static
conclusion. It can evolve over time. However being a summary thread, not one
for discussion [say end-conclusion of UX-meeting]

It would be a slightly different meta-bug compared to the current meta-bug
system. Which is actual nice to have. Reason: I'm personally unable to keep
track of all related bugs. So quite some bugs I will not notice or forget
about. Resulting out of sight, out of mind. 

I'm envisioning a meta-bug: the Table Properties dialog needs a revamp with in
my perception implementing start/end being part of the change. [Yes, it's
subjective]. 

Why didn't you create one already: I'm able to asses if's valid meta-bug. And I
would singly handed introduce new type of metabug (action based); possibly
interfering with current system. It would be a kind of UX change bug-tracking
system. And well volunteers can't add more and more bugs freely. The meta-bug
needs to be actionable. So a rigorous check of scope creep is needed. So each
'addition' to the meta-bug needs to be ultimately accessed by by some authority
(for example during UX-meetings). And some standards: so no general rules. No
more than 10 subtopics. 

---
FWIW: there was request for GsoC projects. Implementing Start/End function
including UI might be something? Not sure if this is feasible.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to