Want to know what my biggest /. gripe is? The story submission process. I've submitted perhaps a dozen stories to /. in my time. One has been accepted. It wasn't even that good. Most of the ones I wrote were Ask Slashdot questions and were world's better than some of the stupid stuff that gets asked on Ask /.. Yet, they were rejected. What's wrong with rejections? Nothing. I'm sure the /. folks see all sorts of submissions and get sick of dumb stories quickly. They probably also had grammatically incorrect stories or stories lacking enough technical content and links as well. Rejects are good if there is a good reason.

This is where the problem comes in. No reason is given for story submission rejects. Why? Probably because there isn't an easy way to do this in SlashCode. Imagine this.

Joe writes a story, previews it a couple times while adding content, then submits the story. A /. editor, lets call him Leroy, reads Joe's story. The story was obviously not proof-read because it's full of grammatical errors and mis-spelled words. The good news is Joe has a good story topic. It doesn't have enough technical content though. Joe forgot to include links to the company involved or an offsite news story. Bad Joe. No cookie for him.

Now, under the existing story submission process Leroy would simply reject the story. I propose that SlashCode have a way for Leroy to provide feedback to Joe on his story. Now I'm sure the /. editors read and reject^H^H^H^H^H^Hconsider hundreds if not thousands of stories each day. Whatever the feedback method is, it can't consume much more of their time if any. I propose the inclusion of a couple menus on the editor's page that lists the most common reasons for rejecting a message. The menus could contains reasons such as

Grammatical errors

Mis-spelled words

Bad links

Rambles

Lacks technical depth

Duplicate story

Incorrect Topic/Section

Topic not meant for Slashdot

Or any other common reasons for rejecting a story. Each menu selection in the first menu of reasons could then change the menu items in a second menu of suggestions.

Proof read

Double Check Links

Make more concise

Find technical content

For example "Grammatical errors" or "Mis-spelled words" could give the option of "Proof read" by default (and "go back to elementary school" as a second option). "Bad links" could give the option of "Double Check Links" by default and "Find a mirror" as a secondary option.

Using these menus would be very simple, almost effortless. There could even be a text field for Leroy to make notes in if they desire. Perhaps the story is good and just needs a couple small changes before Leroy would accept it. Leroy could express this in his own words in the text box if they wish. Now when Joe goes to check his messages, he sees that his story has been rejected. He checks the notes on it and see why. Whoops. It looks like he forgot to proof read his story. Whoops again, he forgot to include the links to the technical specs on that new gizmo. Since this new fangled system lets him edit the story he submitted for X days (new feature please), he brings it up, revises it complete with typo-fixes and new technical data and links. Now Joe resubmits it. Well since an editor, Leroy, has already worked with this story once before, it is auto-assigned to Leroy. Leroy then checks in on his submitted stories. Hmm, looks like Joe revised his story. "Why, this is exactly what I was looking for!, he exclaims . He sees that all the neccessary changes have been made and the story is good enough to accept. Joe checks his messages later and sees that his story was accepted. Joe is happy. Happy is Joe.

Now isn't that a much nicer way to accept and reject stories? Tell me, how many of you folks out there hated math teachers that never gave you the opportunity to correct math homework, even if it was only for half credit? I know I sure did. Did the quality of your work improve because of it? I imagine it did. I submit that the quality of user-submitted stories would increase if such a process were implemented and given a chance.

In all honesty it wouldn't take any more time away from Leroy to use the menus. By setting your default appropriately, one or two menu selections and a click is all Leroy would have to do after reading the submission. That's not too hard or time consuming, is it? Joe is happy because he received actual feedback instead of a big fat rejected on his submission. I'd compare the existing method to having a bank stamp a big fat rejected on your home loan app with no explanation. With my method they would at the very least give you a couple reasons why the loan app wasn't ready for the big time. "Your credit doesn't meet our minimum requirements", "You don't have enough collateral for a loan of this size". Ideally you'd get a couple simple suggestions to go with the reasons, such as "apply for a secured credit card and use it for 6 months to build more credit", "eliminate higher interest debits first, then come back", or "consider using your retirement or motorcycle as collateral". I'd much rather have constructive input than a big fat rejected, wouldn't you?

These menus could be incredibly easy to implement. If I was a half-way decent programmer, I'd submit the source to SlashCode myself. Unfortunately I'm not a programmer by trade. I do think it would be very easy to do though. The menus would be javascript driven. I've done much of that before on my statistic sites and it's not too hard. The story archival for correction feature wouldn't be too hard either I wouldn't manage. Just hold on to the story text a little longer and allow the user to edit a copy of it, then resubmit it back to the assigned editor. That can't be that hard either. This simple addition would greatly improve my impression of story submission process. If I were using SlashCode on my own server (I'm considering it), I as the editor would want to be able to tell my users why I rejected their submission. Otherwise I'm sure they'd call me on the phone to ask why. SlashCode isn't always used in places where the editors and users don't know each other personally and aren't separated by thousands of miles.

That's about all I have to say on this. I have posted two articles to slashcode.com about it in the past and both were received with favortism towards implementation.

"Submission rejection feedback"

"Story Submission Suggestion"

I think it would be a worth while thing to implement. Of course I could always be wrong. I welcome input from other current and potential SlashCode gurus and admins.

A journal have I!