Download it now!
Bug 129806 (Help-osFeatureParity) - [META] Feature "not implemented on platform X"
Summary: [META] Feature "not implemented on platform X"
Status: NEW
Alias: Help-osFeatureParity
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Help
  Show dependency treegraph
 
Reported: 2020-01-05 12:32 UTC by Mike Kaganski
Modified: 2020-01-21 22:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-01-05 12:32:36 UTC
In general, this issue is about the need to mention "not implemented" state of different features on different platforms. This might be a meta?

Specifically, as seen in tdf#98723, remote connection to an SSH server is not implemented on Windows. While it's nice to implement it, still, until it is not, the help ([1], [2]) should include a note like "Note: connecting to SSH server is not available on Windows", to avoid users trying to "do everything as in documentation, but nothing works".

[1] https://help.libreoffice.org/6.4/en-US/text/shared/guide/cmis-remote-files-setup.html
[2] https://help.libreoffice.org/6.4/en-US/text/shared/guide/cmis-remote-files.html
Comment 1 V Stuart Foote 2020-01-05 14:48:58 UTC
Yes, useful guidance to have in the help--maybe using a unique note style?

But is there any place the missing features by platform is cataloged already?  Or would we just create a BZ issue for each and add it here? This is a meta either way.

An example of a non-implmeneted feature needing notice in Help is error reporting on macOS [1]

=-ref-=
[1] https://help.libreoffice.org/6.3/en-US/text/shared/guide/error_report.html?DbPAR=SHARED#bm_id3150616
Comment 2 Olivier Hallot 2020-01-06 22:39:44 UTC
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).
Comment 3 Mike Kaganski 2020-01-07 05:16:51 UTC
(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.
Comment 4 Mike Kaganski 2020-01-07 05:30:27 UTC
(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?