Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Slashdot.org

Journal NetSettler's Journal: Managing Non-Technical Bugs in the Slashdot paradigm 1

I find myself puzzled about how to feed back ideas into the "Slashdot process" about how to make that process better. So I'm thinking aloud here.

I asked about this a long time ago, and I was told to submit reports to SourceForge. But since the reports I submitted were not technical but process (for example, remarks about what moderation keywords should be permitted--I had some new ones to suggest), the SourceForge people were (probably rightly) confused about why I was bothering them.

Last night, I received my first report of meta-moderation having decided one of my moderations was inappropriate. To me, this is plainly a bug, and yet I can't figure out where to submit the report. The bug isn't that someone disagreed with me, or even than many people did. The bug is that they decided they disagreed with me based on the outcome and their inferred notion of why I had moderated as I did, rather than by actual communication.

The fact that the moderation system provides no way for me to say "This was a judgment call, but here let me explain my reasoned opinion." makes it very likely that people who haven't thought as deeply (and yes, I dare suggest that sometimes that will happen) will not understand my choice. It also means that when someone overrides me, they are not asked to explain their rationale to me so I can't tell if they are thinking clearly. ... And in reverse--I am robbed of the ability when meta-moderating to explain why I thought something inappropriate.

I still think I was right and the many meta-moderators are wrong, but that's of little consequence. What is of consequence is that there is no dialog going back and forth which might lead to more enlightened moderators and more enlightened meta-moderators. Instead, people just get more and more entrenched because each camp is sure the other camp is comprised of idiots--the natural effect that always happens when there is blocked communication over use of a necessarily shared resource.

But at the meta-meta-level, the problem is that Slashdot has no procedure for nor place for discussing what might make Slashdot procedures better. Things that are not out-and-out technical bugs seem to have no place at all. And so I'm just making my remarks here, in case they get heard and maybe something gets triggered. Or in case someone knows of a feedback facility that I don't.

I actually think Slashdot has an overall wrong theory of how to manage moderation, etc. However, I respect them for having worked through a theory and tried it, and I think there's value in that even if it isn't what I would have done. It's something about which reasonable people can disagree. And even within a paradigm I myself might not have chosen, I think there are local optimizations that could be made that are appropriate to the chosen paradigm to make it work better. That's what I'm trying to do here.

This discussion has been archived. No new comments can be posted.

Managing Non-Technical Bugs in the Slashdot paradigm

Comments Filter:
  • I don't know that /. developers read random people's journals. (I only saw it because I've marked you as a "friend", so /. notifies me when you make a journal entry. I'm not stalking you or anything. :) Maybe you should do an Ask Slashdot? At least then you'd know that an editor got a chance of seeing it. If they post it, probably somebody out there, maybe lots of somebodies, agrees with you, or at least knows where you should submit your ideas.

    Pray they don't say "so submit a patch!". :-\

    -- Larry

"Money is the root of all money." -- the moving finger

Working...