Topic: Userscripts.org discussion / servers, costs, and ads status

I agree that a donation box seems like a good way to go. I mean, scriptwrites tend to be programmers, and programmers tend to be generous to causes they are fond of. I know I am.

Topic: Userscripts.org discussion / organize script by numbers of installs

Heh, there are greasemonkey scripts that do these things...

Topic: Userscripts.org discussion / Install views source

Note that there is an open thread in the newsgroup concerning an issue with GreaseMonkey 0.6.9 failing to install new scripts.

http://groups.google.com/group/greasemonkey-use...

Topic: Userscripts.org discussion / Error while installing.

Note that there is an open thread in the newsgroup concerning an issue with GreaseMonkey 0.6.9 failing to install new scripts.

http://groups.google.com/group/greasemonkey-use...

Topic: Userscripts.org discussion / Tags in Userscripts.org

Wow was that long.

Topic: Userscripts.org discussion / Tags in Userscripts.org

Feedback!

1. Removing "." is unnecessary: I agree with Johan that machinetags are the way to go here. They're a clean, scalable solution--rather than a hack. They also open the door to other interesting functionality for the future.

As for legacy issues, why not just purge the existing tag database? Active scripts will get retagged, and inactive scripts won't. Is there really a downside to this?

2. Fuzzy Suggest: Excellent idea, but we'll have to watch CPU load on this one. As the tag database scales, running a complicated RegExp across ten thousand entries for each proposed tag in a new script could make us sad, sad pandas. (Especially if we let users as well as authors do the tagging. The problem scales exponentially.)

3. Mistagging: I feel we'll improve data integrity better by relying on user behavior rather than policing (see my suggestion below). As a note, moderation might be a good stopgap if we don't want to wait implement more advanced features before rolling tags back out.

4. Moderating: I don't especially like admins removing bad tags, but I really, really don't like admins removing "unpopular" tags. A pruning process removes some of the *best* information in the database. (See the end.)

So I gave this a little thought. Here are some suggestions.

Suggestions!

My idea has two parts:
5. Tag Ratings: The goal would be to generate a value representing how useful and relevant the tag is for the script. I can think of two ways (which I like) to generate tag ratings:

(A) Users (and the author) would tag the scripts themselves as they browse them. I envision the UI working similar to the del.icio.us FF Add-on interface, where you start with a blank line and a few lists of commonly applied tags. You can either click or type. Each these would be tallied up like a vote, giving us a rating for each tag.

We can get super-fancy here in the future, weighting users differently based on all sorts of things (like, say, being the author of the script, being a frequent contributor, or some sort of user-quality algorithm). Note that this would give us a kind of moderation without distorting or eliminating the data.

(B) Let users "vote with their feet". Whenever a user clicks on a script they found through a tag search, the system would add a vote for that tag on that script. I feel this is by far the best solution, since it scales well and requires practically no maintenance. This obviously requires some sort of bootstrapping mechanism to get started (like A). It also requires some sort of tracking control to prevent malicious users from gaming the system. Logins, cookies, and some rules of thumb would work 90% of the time here, which should be good enough.

6. Searching, Displaying by Tag Rating: Once we have tag ratings, we should use them to help filter and sort searches, much like Google's pagerank. We'd want to sort results based on rating and offer the option to filter them based on a threshold.

In fact, picking the right default for the threshold is what would eliminate the need for moderation. The filter would exclude those "bad" tags from the search results by virtue of their unpopularity. But the benefit over moderation is that the data remains--if the user really wants to see those outliers tags, she can set the threshold to zero.

Problems!

The biggest issue is clearly Overhead.

The tag database (or tables) could quickly become unmanageably large if we don't set them up correctly. Further, there's an inverse relationship between required storage capacity and data integrity: The best way to prevent a user from inflating tag ratings is to store every tag they enter attached to those scripts. That could get costly. (Note we don't have to do that when they "vote with their feet"--we can use server-side session information or some such.) There are algorithmic ways around this, but it could get tricky.

The other major problem is development time. The old system is probably still around and the other changes we're considering are much smaller.

I don't think this is a deal-breaker, though. We can mitigate development time by coding it in phases. We start with the simple model we already have, and keep an eye to extending it in the future--split up some tag information into different database tables, ensure functions take objects and not fixed parameter lists, etc. Later, we could revisit the tag-system after we got the simple version up and running.

As a post-script, I came to this by thinking about tagging conceptually.

Ask yourself: why we want tags in the first place? They're a great organization tool--not because they perfectly categorize things--but because they show relationships between ideas. In this light, we don't want to moderate away so-called "fringe tags". They represent relationships between ideas just as well as any other tags.

Sure, sometimes they're on the fringe simply because it's a mis-tag. Actual mistakes--malicious or not--might be worth removing... But I actually think ratings and filtering provide a better, low maintenance solution.

In all other cases, though, fringe tags can be some of the most useful tags. They could represent very specific ideas about the script ("gmail-for-os-x"), obscure-but-relevant search terms ("hebrew"), or just a minority view on what the script could be used for. The important point, though, is that moderating away these tags is just removing information that is outside the mainstream. (I'm not squawking "censorship!"--we're just talking about metadata here--but it's still not very encouraging that there's a parallel.)

I think the major issue with "tag creep" is actually a usability one. When a script gets too many tags, it becomes difficult for the user to grok the relationships between ideas. This is a built-in tension: tagging works best when scripts have as many tags as are relevant. Two people looking for the same script might type in totally different queries. Our system should be agnostic as to which query is "right"--we should want to provide the best results possible for every search.

Topic: Userscripts.org discussion / Scripts no longer installing

IMPORTANT!

There is an open thread in the newsgroup concerning this issue. Please read through it for additional information (and post if you have anything new to add):

http://groups.google.com/group/greasemonkey-use...

Topic: Script development / Include/Exclude Rules

Good call, Mr. Scum. I checked the wiki, but I didn't spend much time on it... I figured someone clever would be more thorough than myself. :)

And Joel also raises a good point. I could think of some scripts that would be nice to run on things that match certain complicated patterns that involve "/forums/".

Topic: Script development / Include/Exclude Rules

I see a lot of scripts that use two lines for HTTP and HTTPS requests, something like:
"http://foo.bar"
"https://foo.bar"

Now, I'll admit I have a problem. I love elegance and I just can't stop. I try to stay away, but I just keep reducing and purifying code until it's a work of art.

So my question is: Can anyone think of a practical reason not to use "http*://foo.bar" instead?