Re: About the use of the term "anti-feature" in the FSD.

[Craig Topham]

On 12/25/24 21:31, David Hedlund wrote:
> On 2024-12-25 20:08, Lorenzo L. Ancora wrote:
> > @Craig
> > > > > >   I think we should reconsider the use of the term "anti-feature" 
> > > > > > and replace it with something a little more versatile.
> > > > > "Anti-Features" aligns with the naming and categorization found on 
> > > > > the F-Droid Anti-Features page.
> > > > Is the FSF holding any public agreements with F-Droid that would 
> > > > justify keeping such name?🤔
> > > I don't know of any agreements with f-droid.[...] The problem is 
> > > there are other potential aspects of a program which might be worth 
> > > bringing to the attention of or explaining to a potential user.
> > I fully agree: the FSD has the occasion of distinguish itself, 
> > bringing novelty and ethical development on the table.
> > In particular, the complexity of ethics grows with the complexity of 
> > the applications, so the current system can't be considered future-proof.
> > Replacing the old concept with a more flexible one would surely ease 
> > the learning curve for both visitors and young volunteers.
> >
> > "Anti-feature" is a word fit for technical issues, but surely the FSD 
> > needs to also address ethical issues.
> >
> > The beginning of the new year would be a lucky occasion to introduce 
> > the concept of User Notice.
> >
> >
> > @David
> > > I did not explicitly state that there is a public agreement with 
> > > F-Droid.
> > The userbase can ask any question it deems appropriate
>
>
> I believe there may be a language barrier at play here.
>
>
> >   to clear ambiguities.😅
>
> Of course.
>
> > @all
> >   >  Agreed. For starters, can you please add new subsections of your 
> > examples 
> > tohttps://directory.fsf.org/wiki/Free_Software_Directory:Antifeatures#Non-features ?
> >
> > In 2016 Sullivan and Dr. Stallman noted that the names of the 
> > antifeatures were a bit too aggressive.
> > When the FSF needs more friends, appearing irrational or aggressive 
> > isn't a good calling card.🕊️
> >
> > I suggest that the best course of action would be to implement the 
> > following redirections:
> >
> > 1. "Free_Software_Directory:Antifeatures" -> 
> > "Free_Software_Directory:UserWarnings"
> > 2A. "Antifeature: Bait and surrender‏‎" -> "UserWarning: Tiered software"
> > 2B.  "Software with Bait and Surrender antifeature‏‎" -> "UserWarning: 
> > Tiered software"
> > 2C. "Software with Nonfree Compensation Software Promotion 
> > antifeature‏‎ " -> "UserWarning: Non-free software promotion‏‎"
> > 2D. "Non-free software promotion‏‎ " -> "UserWarning: Non-free 
> > software promotion‏‎"
> > 3. "Antifeature: Free fork needed!"‏‎ -> "UserWarning: Free fork missing"
> > 4. "Antifeature: Software names with words to avoid: Linux‏‎" -> 
> > "UserWarning: Ambiguous terminology"
> >
> > After that, the road ahead will be much less steep.⛰️
> >
> > ~Lorenzo
>
> Looks good! I'm fine with you applying these changes. Do you agree, Crag?
I suggest we hold off making changes until we have collected all the 
information. I know this slows things down, but I feel it is the best 
way to be thorough and reduce the chances of having to make changes in 
the future.

I for one think the hierarchy should have UserWarnings at the top and 
that antifeatures are a type of warning.

Another example: Using a "word to avoid" is not an antifeature, but it 
does fall under a warning to let users know the project might not align 
with our values.

David: I will add to the antifeature list as you suggested, so we can 
keep collecting and go from there. WYDT?

~craigt