On Sun, Feb 09, 2014 at 10:42:39AM +0800, Paul Wise wrote: > On Wed, Dec 18, 2013 at 03:25:45PM +0100, Bill Allombert wrote: > > > Policy could include a word of warning about hypertext documentation. > > I reported #738176 against lintian because I noticed Debian contributors > taking incorrect actions (for eg #738101) based on the lintian tag > descriptions. Bastian asked me to come up with some wording for this > section of policy, here is a combination of what I have recommended in > the lintian bug plus some rationale on privacy and the Social Contract: > > Local HTML files that use resources (scripts, images, audio, video etc) > that are located on remote servers are a privacy breach for users who > view them in web browsers. On the other hand many of these remote > resources are used for promotion of the upstream projects that Debian > contains. Promotion of upstream projects is essential for their > continued use and development and is good for Free Software as a whole. > The Debian Social Contract suggests we should balance the interests of > our users (privacy) with the needs of upstream projects (new users and > continued development). The best way to do that is to use local > resources instead of remote resources. Please replace any scripts, > images or other remote resources used by HTML files in Debian packages > with non-remote resources. It is preferable to replace them with text > and links but local copies of the remote resources are also acceptable > as long as they don't also make calls to remote services or resources. > Please ensure that the remote resources are suitable for Debian main > before making local copies of them.
For me there are several points: 1) the documentation must be self-contained, and do not require internet access to read it. 2) the documentation must respect the user privacy (if the user is connected): 2.1) automatically loaded resources must be _local_. 2.2) <a> link to outside resource are OK as long as it is made obvious this is not an internal link. I am not quite sure I understand your point about "Promotion of upstream projects". What example do you have in mind ? (I see the burden of providing proper documentation as belonging to upstream. It they fail to do it, they can hardly blame the Debian maintainer for their change). Cheers, Bill -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140209221134.gb23...@pari.math.u-bordeaux1.fr