Re: Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
On Sun, 2002-03-17 at 11:48, Steve Langasek wrote:
> On Sun, Mar 17, 2002 at 02:07:01AM -0500, Jeff Licquia wrote:
>
> > As I've mentioned in another message, I'm not interested in targeting
> > swear words or mild stuff. I'm hoping that this will catch packages
> > with highly offensive stuff, like the joke mentioned in this thread.
> > The point of the voting system is that a package would have to contain
> > something really bad before it would get onto a list like this.
>
> OTOH, you've also said that you will abandon the experiment if
> developers don't get it, which implies that there's yet another set of
> criteria being used to measure the success of the project, above and
> beyond developer votes.
True; this was mostly aimed at people who were proposing to try to
censor emacs, perl, and the like because of some purported "moral
offense" they take at those packages. I took that as an indication that
some people who disagree with the entire concept were willing to exert
effort in an attempt to make the package unusable for its primary
purpose.
To counter that, I was going to make the justification mandatory, and
reserve the right to invalidate votes that don't have sufficient
justification. I'm sure you can see the trap there - who am I to decide
that justification isn't "sufficient"? More flame wars.
> I'm always in favor of tools that give users more information, and this
> tool definitely fits into this category -- /if done right/. A blacklist
> that's assembled with respect to a publically available list of
> measurable criteria would be useful to many people. Those who agree
> with the criteria benefit from having a package they can use on their
> systems. Those who agree with /some/ of the criteria benefit by having
> a list available that they can check against. Those who believe that
> censorship of the archive is wrong benefit from being able to placate
> those who hold a different view.
>
> Using voting to determine membership in the blacklist, however, lends a
> faux legitimacy to this package that it cannot and should not have.
> There should be nothing morally authoritative about such a package. If
> you say "these are the packages that contain homophobic jokes about
> Hindu bitch-cows from the Bible belt", users can decide up front whether
> to take it or leave it. If you say "these are the packages that are
> allowed to exist in the Debian archive, but that 8 out of 10 Debian
> developers believe are morally wrong", the only people you benefit are
> those who are willing to subvert their own moral judgement in favor of
> that of the Debian community -- and THAT offends /me/ more than anything
> else that's been discussed in this thread so far.
Well, the idea originally was that the vote would act as a first
approximation, with a conflict resolution system of some kind to ward
off abuse. I think, though, that the conflict resolution system is
being forced to take more and more importance.
The question of conflict resolution is one I've been punting on, hoping
that someone would have a good idea about that. My own thoughts on the
subject have all revolved around the Project having some level of
buy-in; this obviously hasn't happened.
> > Up to now, censorship has been a matter of the developer's choice, and
> > is thus exposed to the wrath of offended users. Since users have no
> > recourse other than by harassing the package maintainer, you end up with
> > developers self-censoring (before the fact, even) to relieve or avoid
> > the pressure. I don't want to take power over a package away from a
> > developer, though; rather, I'd like to divert the users' wrath away, so
> > the developer can make choices about the package that aren't based on
> > relieving peer pressure.
>
> The types of users who would rather harrass developers to change their
> packages than simply remove the package from their own systems aren't
> going to go away under your plan.
Unfortunately, I see your point here.
Note that I'm withdrawing my proposal. I still agree with the general
goal: provide a way for people to figure out what they might object to
without having to audit the project or be unpleasantly surprised one
day. It seems that my solution has too many holes to be workable.
Reply to: