Re: [directory-discuss] Anti-features going forward

[Nomen Nescio]

Donald Robertson said:

> We should focus on making the Directory more comprehensive and up to
> date before getting too deep on features that are more about adding
> evaluations to the entries that are already there.

Regarding this sequence of work, consider this: The "nonfree
documentation" category exists but it's in a bad state.  Editing the
database without first getting the criteria right seems like a risk
for rework.  When someone is updating a project listing, that is the
convenient moment to see if the flagging matches the criteria.  If the
flagging criteria is not first stabilized, records will likely be
introduced with inaccuracies, and cause banner flip-flopping.

> We want to make sure the Directory serves users well, and that does
> include considering ideas for evaluating programs beyond the fact
> that they meet the Directory's minimum standards. But our current
> priority is pulling in the basic facts about all the programs out
> there that meet those standards.

The anti-features are the single most important feature to the
directory.  Anti-features aside, the first port of call for users
looking for tools is normally the repository of their distribution
(not the directory).  Why would that change?  Even when the directory
reaches the point of having an accurate inventory, it is the package
managers that show users what packages are vetted (working and
supported) on their particular platform.

Repositories don't show users the anti-features.  The FSF directory is
a very useful resource for users to appraise the freedom of the
software.

Concrete example:

There are half a dozen packages for spaced repetition (memorization)
on debian, and probably more outside of debian.  A debian user
generally shortlists those officially supported.  Someone who chooses
Anki may get burnt, because they may only discover that the user
manual is blocked after making the effort to install it, configure,
and grow the database of words.  The anti-features in the FSF
directory will counter that so users can make better decisions.

> We also want it to be a quality tool for maintainers of packages.
> They're not going to find it a very useful tool if they are getting
> blind-sided with warning messages on their entries, particularly if
> they are just popping up and disappearing without warning.

Indeed.  This is exactly why it's important to get the flagging
criteria right early on.

Just today the Anki project has stopped blocking Tor, which is
progress for user freedom.  This came just a couple days after
flagging Anki with the "nonfree documentation" flag.  Apparently the
flagging in the FSF directory may have compelled Anki admins to make
an important change support user freedom.

But we actually got lucky there, because the criteria for which Anki
was flagged has been removed.  We need an FSF rep to restore this
deletion (which occured prior to any discussion, and for which the
current state is inconsistent with what was established in the
discussion):

  
https://directory.fsf.org/wiki?title=Free_Software_Directory%3AAntifeatures&action=historysubmit&diff=40983&oldid=40979

> For some projects there are means for resolving the issues we may
> have with them. If a problem is big enough to warn users about, then
> it is worthwhile to try and correct it where we can. In particular,
> GNU project packages all have means for fixing any particular issue
> that might exist in the project, and we should go through those
> processes to correct any problem should it exist. There shouldn't be
> anything in a GNU project package that we would need to warn users
> about, so if there is a problem we must fix it.

Can you clarify how to resolve problems with GNU projects?

The GNU Radio staff are quite hostile toward Tor users.  There was a
civil discussion among users regarding the freedom loss due to the
project's use of CloudFlare.  The discussion took place in #gnuradio
on freenet.  After the discussion was over, a gnuradio moderator
removed Tor users from the channel without warning.  Considering the
CloudFlare discussion was quite civil, the uncivil reactionary
response indicates the GNU Radio admins' reluctance to address the
problem, and in fact shows that they've put themselves beyond scrutiny
and above criticism.  I personally will not contribute code or money
to any project that is managed with this kind of conduct.

What's the official process for redress?

--
Please note this was sent anonymously, so my address will be unusable.
But I will check the list archives.