The following was a suggestion email message submitted to the sysops of
/.:
Sometimes /. is *VERY* frustrating. It has some good points, and a lot
of potential, but it could be so much better. I'd actually offer to
help pay for some of the obvious improvements, but looking at it as a
business model, my conclusion is that I'd have to be crazy to invest
much money in your system. I am looking for better investments than
Euros and Japanese real estate, but /. doesn't seem to be a candidate,
in spite of its potential...
Anyway, on to the suggestions. Two of these are fairly minor items,
but thinking about them gave me an idea for a more substantive and
profitable suggestion that I'll offer first: You should sell
"improvement funding" for /. enhancements. The way it would work is
that you would evaluate potential improvements in the code, and the
cost of implementing those features. Then you post those ideas and let
people contribute towards the costs. When a particular idea reaches
the funding level where it is paid for, then you would implement it.
Probably best to do it with a new section, like enhance.slashdot.org,
with a list of proposed enhancements, public discussion of each one,
and the current level of committed funding that people have donated.
You don't need to be exact about the cost, but you should be able to
estimate roughly how much programming time is involved. The cost of
each project should also include the total costs of the evaluation,
and that also needs to include the evaluations of projects that never
got funded. (I don't know if you have staff meetings for enhancements,
but you should, and that's a legitimate business cost.) Also, you
should include the costs of testing and other expenses related to
improving the system.
As a concrete example of how this would work, I'll describe how this
proposal would apply to my second suggestion. This one is only a minor
problem, but annoying: first poster stupidity. It just contributes
noise. Enthusiastic, rarely witty, but usually stupid. My suggestion
is that you put in some timing constraints on the reply function that
would inhibit this form of stupidity. The exact constraints are not
important, but let's suggest a "short-reply block" on the first post.
Any non-subscriber who tries to make an extremely short initial post
will be suspected of first-post abuse, and they will be told they have
to wait for a few minutes before they can post--by which time some
real poster will have had time to make a substantive comment with real
value.
You would evaluate this suggestion and might determine that it would
take about 5 hours of programmer time at $50/hour, for $250, plus it
took 20 minutes to discuss it in your improvements meeting of three
people for another man-hour, for a total cost of $300. Let's call the
overhead 33%, and you'd evaluate the cost of this improvement as $400.
We'll say that in this case you don't need much time for preparing the
post because the original submission is adequate to start the
discussion in enhance.slashdot.org.
You might group this proposed enhancement with several other
suggestions to address the same problem. For example, someone else
might have suggested a first-post relevance-based filter that is
estimated to take 80 hours of programming time. (It would compare the
linked articles to the submitted post to see how likely it was that
the poster had actually read the article, and also check for too much
cutting-and-pasting.) Readers of /. could look over the ideas, make
comments, and even contribute to the funding of any idea. If possible,
this should be done with some kind of dynamic meter so people could
see how that project was doing for funding. I'm thinking of one of
those thermometer things. When the funding is available, then you
schedule the implementation. You could even include a priority factor
with some extra funding for rush jobs.
(Two more wrinkles should be mentioned:
Wrinkle One: What about projects that don't get enough funding? I
think you should explicitly state that you will keep those donations
for other improvements. However, all of the people who donated to that
project will be notified when it is about to expire, and any of them
can request that the discussion be extended. For example, the default
funding period might be one month, but someone might want to insist on
discussing it for another month. That person would have to add some
explanation to the top post of the discussion to explain why he or she
thinks the idea is still worth implementing.
Wrinkle Two: What about removing features? I think you should treat
them as "code streamlining enhancements" that would be proposed and
funded in the same way. However, these would probably usually be
prepared internally by /. programmers based on evaluating substantive
problems with the actual code.)
Okay, now for the third suggestion, which is related to the continuous
problems with moderation. (However, in the funded suggestion scenario,
these moderation problems would actually be a source of ongoing
funding for /. enhancement, thus converting the problems to something
useful.) I think the moderation reports should include the identity of
the moderator. This would make it relatively easy to spot moderators
who are acting out of personal vindictiveness. I strongly believe that
often happens to me, but I'm actually proud of having certain nasty
little people as personal enemies. For example, it doesn't bother me
at all when some racist religious fanatic is attacking me, but at the
same time I don't much like it when they can use your moderation
system to do it anonymously.