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

Reply via email to