Re: [directory-discuss] 'Bait and surrender'

[Ian Kelling]

On Sat, Dec 17, 2016, at 05:53 PM, Svetlana Tkachenko wrote:
> Hi Ian,
>
> Ian Kelling wrote:
> >  [...]
> > You wrote, "should not have any gateways to proprietary at all in any
> > form whatsoever", and gave an example of linking to one site, which
> > somewhere on it includes a bad links, but this is not what the free
> > software distribution guidelines say, and it would not be practical. The
> > free software distribution guidelines says "it must take care not to
> > recommend nonfree software." Icecat prominently includes links to
> > wikipedia and duckduckgo, and people use those to find software, and
> > they include tons of links to nonfree software, and I'm sure wikipedia
> > links are included in other parts of free software distros too.
>
> Wow yes.
>
> > It
> > doesn't make them non-free. We can't blindly say that because somewhere
> > in a domain there are links to proprietary software, we won't link to
> > it.
>
> It is my opinion that we need to have a catalogue of free website
> resources (with freely licensed content, with free software on it) and
> edit GNU IceCat to warn the users who visit a website whose licence and
> lack of proprietary software are unknown. HTML markup has licence tags
> and attributes which could facilitate this task.

Yes, I agree. This is a big thing.

>
> Ian Kelling wrote:
> > [...] Specifically, increasing the quality and
> > comprehensiveness of our articles and the number of contributors should
> > be our primary focus. Ask, "how often does fsd get used when someone
> > tries to find some new free software for some task", I think it's
> > probably a low single digit percentage.
>
> This is true - there are some things which would be helpful:
>
> A) not using the default mediawiki skin
> - having large 'edit', 'add entry', 'leave a message' buttons at the top
> prominently - worded in clear verbs, the current tab names are confusing
> and some of them are redundant and some are missing
> - having a 100% wide search bar across the page top
>
> B) having a proper list of categories and selectors in the sidebar when
> looking at the search results - I do not know how to do this, sorry! We
> could ask for help here:
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
> C) having a simple version of the new entry form, without the advanced
> fields
>
> Ian Kelling wrote:
> > Most people try searching
> > package descriptions in their gnu/linux repos and using web search
> > engines, and search engines don't link to the fsd very much.
>
> I wonder why. I checked SEO guidelines.
>
> https://www.mediawiki.org/wiki/Category:Search_engine_optimization_extensions
> may be interesting.
>
> 1. FSF Directory does not have META description tags.
> 2. FSF Directory's mobile friendliness is poor. I would suggest
> installing https://www.mediawiki.org/wiki/Skin:Refreshed (or surfing
> https://www.mediawiki.org/wiki/Category:Mobile_skins for other options),
> altering it to make the search box bigger, and making it show the needed
> buttons across page top.
> 3. FSF Directory takes 8 seconds to load.
> 4. We seem to have Piwik on the site, but we're not watching its output.
>
> Svetlana.

Very astute observations. #3 has especially been on my mind.

I think #2 is best solved by upgrading to the latest mediawiki. We are a
few years behind. People are most familiar with the default wikipedia
skin (Vector), if we upgrade, we get a mobile friendly Vector version,
and keep the familiarity people have with wikipedia. And I think point A
is best solved by tweaking the new version of Vector. I've done this a
bit myself before, so I know it's feasible.

Upgrading will also help with #3, but it might also require fsf giving
the fsd faster hardware. I don't imagine the hardware required would be
especially costly. But it makes sense to do the mediawiki upgrade
first and see how much that helps.

So, the testing of the upgrade and creating a script can be done by a
volunteer, with just a little help from fsf to give them the clone
data. Then an fsf employee will need to mostly take over, do the test
upgrade themselves to verify it and understand it and then do the live
site upgrade.

Point B/C. Agreed. For C, at least make it simpler, like labeling what
fields are optional, having a "today" button for date fields, etc. But
for both, does the latest version of mediawiki/semanticwiki have
features that help with this, or is the solution different under the new
version?  I don't want to spend time improving the old version only to
find out it's not applicable to the new version.

For #1 wikipedia does not do meta description tags, so I'm thinking
this is at least not high priority.

#4, yes, but piwik is designed to keep access nonpublic. I've clicked
through piwik on my own small sites without getting any insights about
how to get more traffic, so we should figure out specifically how / what
we want from piwik before we ask fsf for piwik info.

It's on my todo list to work on getting fsd upgraded. I'm just not sure
when right now.