[Libreoffice-bugs] [Bug 129806] [META] Feature "not implemented on platform X"
https://bugs.documentfoundation.org/show_bug.cgi?id=129806 Thomas Lendo changed: What|Removed |Added Summary|[META] - Feature "not |[META] Feature "not |implemented on platform X" |implemented on platform X" CC||thomas.le...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 129806] [META] - Feature "not implemented on platform X"
https://bugs.documentfoundation.org/show_bug.cgi?id=129806 --- Comment #4 from Mike Kaganski --- (In reply to Olivier Hallot from comment #2) > The point in adding to the Help is the maintenance work to keep contents > precise and updated. > > Suppose that the issue on WIN/ssh is fixed someday. Who will pick the right > Help pages and correct its contents? Or, how to let Help maintainers know > the issue is fixed/implemented/whatever? It seems hard to me to traverse > Help pages checking for bugs fixed or new features. The same is true for anything: imagine we have help pages for, say, print dialog; and then GSoC suddenly introduced a new version of the dialog. What would be the difference in this case? I see tremendous progress in our help in recent years thanks to your brilliant work. In AskLibO, I always post links to the related help pages when I know them. And you know what: I see increasing number of such links from others; and direct comments like "the help system is really useful" (I need to have a habit to notify you of such things). It's only possible because help becomes relevant. This request is another way of *helping* users, which is the point of help, isn't it? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 129806] [META] - Feature "not implemented on platform X"
https://bugs.documentfoundation.org/show_bug.cgi?id=129806 --- Comment #3 from Mike Kaganski --- (In reply to Olivier Hallot from comment #2) > I wonder if we can implement an extra field in bugzilla bug report to > indicate the associated help pages to touch. Either way, it is a hard and > time consuming job. It would be awesome; but in the mean time, simply mentioning a commit with the changes, or a list of pages, in the comments - as in comment 0 - will do IMO. > Another drawback is more in the marketing side... It looks bad for a > product/software to let user know it is broken, even on the weirdest corner > case. Better let user discover bugs by him/herself. Strongly disagree. Not implemented state is not a bug, but a missing feature - and the bug is bad documentation which suggests users trying what is *not supposed to work*. While documenting bugs in help would be even wrong because of ever-changing state of the bug - the help must reflect the intended, correct operation of the software (and any non-conformance of software behaviour to what is in help is a bug that should prompt for a report); and "ssh is not expected to work on Windows" is the correct status of the feature. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 129806] [META] - Feature "not implemented on platform X"
https://bugs.documentfoundation.org/show_bug.cgi?id=129806 --- Comment #2 from Olivier Hallot --- The point in adding to the Help is the maintenance work to keep contents precise and updated. Suppose that the issue on WIN/ssh is fixed someday. Who will pick the right Help pages and correct its contents? Or, how to let Help maintainers know the issue is fixed/implemented/whatever? It seems hard to me to traverse Help pages checking for bugs fixed or new features. Very few dev's and QA volunteers care to report changes in the Help, but those who do are my heroes. I wonder if we can implement an extra field in bugzilla bug report to indicate the associated help pages to touch. Either way, it is a hard and time consuming job. Another drawback is more in the marketing side... It looks bad for a product/software to let user know it is broken, even on the weirdest corner case. Better let user discover bugs by him/herself. Some companies publish the "known bugs" list at release time, but that not so often to see nowadays (and very few read it). -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 129806] [META] - Feature "not implemented on platform X"
https://bugs.documentfoundation.org/show_bug.cgi?id=129806 V Stuart Foote changed: What|Removed |Added Summary|META - Document "not|[META] - Feature "not |implemented on platform X" |implemented on platform X" |state of features | -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
