I closed the bug as INVALID and put a comment on there. I also will move the list to the wiki, not sure where it's preferred to go or if I'm making a new wiki page. Thanks for the feedback<div> </div><div>Joel <div class="gmail_quote">On Fri, Jul 13, 2012 at 8:56 AM, Eike Rathke <<a href="mailto:erack@redhat.com" target="_blank">erack@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Joel, <div class="im"> On Wednesday, 2012-07-11 15:53:07 -0700, Joel Madero wrote: > I'd like to make a meta bug for functions that Excel has but that aren't > currently supported or are problematic in Calc. This stems from FDO 47164: > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=47164" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=47164</a> </div>Taking Regina's answer this actually was about <a href="https://bugs.freedesktop.org/show_bug.cgi?id=46918" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=46918</a> For my takes on this topic see the mail I just sent to you and the QA list. And now we have the situation that cross-posting to multiple lists isn't always a good idea because each list doesn't know how things evolve on the other list, as answers on the QA list apparently did not include the dev list and vice versa. So, I'm including my answer here again: <div class="HOEnZb"><div class="h5"> | On Friday, 2012-07-13 07:46:36 -0700, Joel Madero wrote: | | > Thanks for responding Eike. Summary is that I was bug triaging and came | > across a bug that had a list of functions in excel that are currently not | > supported in LO. | | Cross-reading the dev list I found | <a href="https://bugs.freedesktop.org/show_bug.cgi?id=46918" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=46918</a> | with a nice attachment listing functions. | | > 1. Leave excel bugs as is, keep that bug open with the list of functions, | > in the comments I'll confirm individual functions as problematic in LO | > (harder to track progress, harder for devs to pick up individual functions | > out of the list) | | Better close the bug that otherwise would live for months and years and | end up with 300 comments or so that no one would read anyway.. better | add the there attached list (that would be outdated already after the | first function was implemented) to the wiki from which individual bugs | or implementation notes could be linked then. Such "implement dozens of | features" bugs weren't helpful at any time. | | > 2. Leave excel bugs as is, close bug that has so many functions in one, | > tell user that we need them as individual bug reports (easier to track | > progress this way) | | We really don't need dozens of bugs open one for each function not | implemented. I'd rather prefer to open a bug for a specific function | only once a developer starts to implement it so we can (discuss if | necessary and) refer it in the commit summary when done. Also, if users | open bugs for functions they actually miss in their daily work it helps | us more than doing that ourself in advance for all functions we know. | | > 3. Make a meta excel bug just for the functions, then I'll create | > individual bugs for each bug listed by the user and make the meta bug | > dependent on them (similar to most annoying) | | See above about my take on creating individual bugs, plus I don't see an | advantage in having a meta bug for this unless it would be there to have | a quick listing of its dependents. | | > 4. Make a meta excel bug, separate the function bug into individual bug and | > make meta bug dependent on ALL excel bugs (not just the functions one from | > the original FDO) | | We might also use something like an interoperability whiteboard keyword | or some such to query for instead. | | Well, you may have deduced from my answers that I'm not a friend of meta | bugs, unless they are there to mail a pointer to the dev list like the | most annoying meta bugs. In short, it's ok for me if QA wants to create | a meta bug to track existing things, but opening a bunch of bugs to be | tracked just for the sake of having everything in that we _might_ want | to implement over time of years doesn't make sense to me. | | > Michael CC'ed you on it because he said you're currently the go to for | > excel compatibility. My argument is that anything to make it easier to be | > fully compatible with Excel is a plus if the goal is to convince MS Office | > users that we can provide a better product than MS can. | | Specifically when having dozens of bugs open for functions that only | a very minority of users would use anyway it would be counterproductive | pointing potential users to deficiencies they otherwise would even never | have noticed or heard of ;-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD </div></div></blockquote></div> </div>