Web lists-archives.com

Re: Proposed change of offensive packages to -offensive




Iain R. Learmonth writes ("Re: Proposed change of offensive packages to -offensive"):
> I may have been not entirely serious in that example. As the insults are
> not enabled by default, most users will never see them, though they are
> compiled in.
> 
> If there was to be a policy, it should include something along the lines
> of "maintainers should tend towards the least offensive build options"
> but worded in such a way that compiler optimisations and hardening
> options are not subject to an offensiveness rating.

I'm not sure we want to put that kind of recommendation in policy.
Mostly, it's a matter of good judgement.  (Maybe the policy could
refer to the GR-agreed diversity statement.)

So to be concrete, how about this:

  N. Packages with potentially offensive content

  As a maintainer you should make a judgement about whether the
  contents of a package is appropriate to include, whether it needs
  any kind of content warning, and whether some parts should be split
  out into a separate package (so that users who want to avoid certain
  parts can do so).  In making these decisions you should take into
  account the project's views as expressed in our Diversity Statement.

  If you split out (potentially) offensive or disturbing material into
  a separate package, you should usually mark this in the package name
  by adding "-offensive".  For example, "cowsay" vs
  "cowsay-offensive".  In this situation the "-offensive" package can
  be Suggested by the core package(s), but should not be Recommended
  or Depended on, so that it is not installed by default.

This is hopefully vague enough that everyone can agree it ?

> Maybe we can experiment with some voluntary guidelines for maintainers
> to work out any bugs *before* we merge it with policy?

IME trying to write guidelines like this often involves arguments over
hypothetical or unreal situations, and can raise a lot of concerns
that don't need to be resolved in practice to solve real issues.

Ian.

-- 
Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.