[PATCH] Revert "menu: add Adult category to registry"

[Joseph Krahn]

On Thu, Dec 1, 2011 at 3:07 AM, Vincent Untz <vuntz at gnome.org> wrote:
> Hi,
>
> Le mercredi 23 novembre 2011, à 13:38 +0000, Peter TB Brett a écrit :
>> This reverts commit c51aa112f53adc87250177002aa3e008305e0777.
>>
>> There are several serious issues with the stated rationale for and
>> intended use of the "Adult" Additional Category that have yet to be
>> resolved.
>
> FWIW, I don't care much about that category. But:
>
>> - The menu specification is designed for worldwide application, and
>>   thus must be culturally impartial.  Different cultures have
>>   different criteria for something that is "adult-only".  Ambiguous
>>   examples provided on the XDG list include "Bible" and "Art Gallery"
>>   applications.
>
> True. But on the other hand, past examples have shown that we can be
> blocked forever (for instance: the discussion on something like a
> Religion category). And moving forward with something that is not
> perfect is better than staying blocked.
>
>> - Given a set of criteria for what constitutes "Adult" content, the
>>   categorisation is binary, but whether an application is "Adult" is
>>   not.  Ambiguous examples provided on the XDG list include a
>>   "Breastfeeding Tutorial" application; the "PornView" application,
>>   which does not in fact include or provide access to any pornography;
>>   web browsers, which provide access to a wealth of pornography on the
>>   Internet; and text adventure games that include the possibility of
>>   violent death.
>
> Hrm, this is probably an argument that is valid for all categories :-)
> It's really up to app developers to use the relevant categories, and
> then to distributors to decide if those should be overridden or not.
>
>> - The purpose of the "Category" field in .desktop files is to aid in
>>   organisation of applications into a navigable hierarchy.  By
>>   contrast, the proponents of the "Adult" Additional Category view the
>>   "Adult" additional category is as a tool for censorship.
>
> Hrm, I don't think it's censorship: the apps are still there, after all.
> It's filtering, and filtering is actually what the menu spec is about.
> Sure, in this case, it's filtering to hide stuff.
>
>> Until these issues are addressed and consensus is achieved, this
>> category should be removed.  In the interim period, there is no
>> obstacle to Menu Specification implementors using Additional
>> Categories not listed in the Specification, should they wish to do so.
>
> Do you see any way those issues can be addressed?
>
> The way I see it, it's just additional metadata that is not used by
> default and that people can use if they want. So I'm not that much
> worried about it.
>
> Vincent
>
> --
> Les gens heureux ne sont pas pressés.
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg

The main problem of "Adult" as a category is that there are very few
applications that are sufficiently "adult" oriented to actually fit
this category as a primary description. People would be more likely to
misuse it to exclude applications from their appropriate category, in
an attempt to hide them from children, or exclude them from public use
locations.

IMHO, one significant concern is over applications oriented toward
pornography, including the fact that is is prohibited in many places
where Linux is used, such as my own office. Even that usage has
problems. First, one could argue that pornography is not exclusively
for adults, and the definition of pornography is imprecise (e.g. women
in bikinis). It would be better to classify as Erotica. But, that
still won't work to exclude applications with erotica, because
Applications whose primary category is something else can still have
some erotica.

Overall, Peter Brett's assessment is very good. Adult software is
mostly about content rather than functionality. There may be a few
valid uses for an Adult category, but it is more likely to be a
nuisance. It is probably better to use a system of keywords that can
be used to filter based on content, with as many keywords as needed to
help support the multiple opinions and preferences, and perhaps at the
package management level.

Joe Krahn