Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Edit/Cancel own story option required?

By Paul Johnson in Meta
Thu Sep 28, 2000 at 09:36:36 AM EST
Tags: Kuro5hin.org (all tags)
Kuro5hin.org

Does the story submission and moderation system needs an option for authors to cancel or edit their own stories?


A few days ago I submitted my first article to Kuro5hin, about why OSS hackers don't use CASE tools. A number of people commented that this was an interesting and worthwhile topic, but my write-up left a lot to be desired. A lot of others asked "What's CASE?".

I decided to take these comments on-board and rewrite the story. Unfortunately the goodness of the subject seemed to outweigh the badness of the writing for the majority of voters, and at the time of writing the vote is running at 292:239 in favour of posting it. I have no control over this process. There is no "Cancel submission" option available to me, and I have been reduced to posting a pitiful reply asking future readers to vote the story down.

There are some issues with such a system. Along with the editorial comments on my story there is also some topical discussion about the question I posed. It would be nice to be able to bring this over to a new submission. So maybe a rewrite option? But that would encourage changes during the moderation process which answer topical disagreements. To later readers it would look like the early topical posters had simply not read the story properly. It would also reduce the premium on thinking about your story hard before posting it (I admit, I composed mine in a hurry before going to bed).

So the question I ask is: should these options be added to Kuro5hin?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Does the submission & moderation system need...
o A Cancel story option 35%
o Cancel and Edit options 63%
o No change 0%

Votes: 138
Results | Other Polls

Related Links
o Kuro5hin
o my first article
o Also by Paul Johnson


Display: Sort:
Edit/Cancel own story option required? | 48 comments (46 topical, 2 editorial, 0 hidden)
I think this is a perfectly valid question. (2.80 / 15) (#1)
by andr0meda on Thu Sep 28, 2000 at 08:15:49 AM EST

So I rated this topic +1.

It seems a lot of discussions about a subject start allready during the moderation phase, which should only give critical insights whether the topic is worth discussing in the first place. Never mind that. However, since we have this valuable soundboard to check other opinions, it seems only logical we should be able to alter or update our own posted stories, otherwise I don`t see the benefit of discussing and validating entries in the first place.

So I definately gave it a + :)



Do not be afraid of the void my friend, is it not merely the logical next step?
Absolutely! (3.07 / 14) (#2)
by Pakaran on Thu Sep 28, 2000 at 08:17:35 AM EST

I had an experience last night in which I posted two stories, both of which got turned down. The first had some typographical errors, but nonetheless 3 people (iirc) felt it had promise, and one even posted a comment saying so.

I did my best to fix it but readers didn't like that version either. Now, if I intended to submit it again (which I'm not sure I even will), I would have to decide which of about 5-6 recommended changes would be best to include. Also, if I had been able to cancel the first submission, I could have immediately directed peoples' attention to the second.

Can I change my vote too then? (3.62 / 16) (#3)
by duxup on Thu Sep 28, 2000 at 08:38:32 AM EST

I hope then I could change my voting as well when you change your story, and have some sort of display in the Moderate Submissions section to denote edited stories.

EXAMPLE: If you changed your story to explain what CASE is I might want it on the front page rather than just that section.

Personally I don't have a problem with people resubmitting stories that already have been rejected if they've made some changes.

This is exactly what I'd like to see. (3.55 / 9) (#4)
by Anonymous 242 on Thu Sep 28, 2000 at 09:07:25 AM EST

(1) Allow article submitters to edit their stories and upon editing give an option to restart voting or not. If voting gets restarted, all topical comments remain and vote goes back to zero and everyone gets to revote. So if the article author chooses to restart voting, even if I've already voted on the article, it will show up in my queue as not being voted on.

(2) I'd also like to see the ability for voters to change their vote whether or not the story has been changed. There have been times when I've voted one way or the other on a story and then had a turn in the topical comments change my mind.

(3) I'd like to see voting continue while a story moves to the front page or the section. I wouldn't allow a published story to disappear but I think voting should continue on whether it shows up on the front page or only in the sections.

[ Parent ]

Oh yeah.... (3.04 / 21) (#5)
by FlinkDelDinky on Thu Sep 28, 2000 at 09:14:41 AM EST

I've been asking for this since long before "The Bad Thing" (AKA The Dark Age) happenned.

Since I haven't submitted a story since The Resurection I'd assumed the Enlightenned Ones (AKA PERL Hackers) had corrected this. Well I gues not. Huh, I'm kind of astonished. It's not like this hasn't been talked to death prior to the Dark Age.

Here's how it should work:
The writer of the story should have two options when he looks at it in the voting que:
Rewrite Story
Delete Story

Rewrite story would take him back to the story submishion page were he could edit to his harts content and resubmit.

But what about the the old stories comments? Well you dump the editorial (red) ones but you keep the regulor discussion (blue) ones. However, you mark the blue ones so that readers know that they're from a previous submission of the story (maybe some text at the top that says 'This comment posted from X version of this story.'.

Since all story submitters want this and have wanted this and it's been promised pretty much from the begginning and it's pretty gad damn important to story quality and it's a pretty good idea to boot I kinda expect something like this will be added within the next five to ten thousand years or so but then again maybe not, this after all Kuro5hin and we never really know what's going to happen next do we? No, of course we don't that's why we just go with the flow and roll with the punches and let the chips fall where they may. It's not as if stories are important to this site, chhrist I don't even know why we need stories and that god damn submission que. Christ, who needs that? Lets just have a posting area. K5 is by the users and for the users and God knows that writers aren't important enough to be considered users of K5.

Everything is okay, I'm feeling much better now.

Re: Oh yeah.... (4.75 / 4) (#25)
by rusty on Thu Sep 28, 2000 at 04:03:49 PM EST

Since I haven't submitted a story since The Resurection I'd assumed the Enlightenned Ones (AKA PERL Hackers) had corrected this. Well I gues not. Huh, I'm kind of astonished. It's not like this hasn't been talked to death prior to the Dark Age.

If you were reading my comments to various news outlets during the downtime, one of the frequently repeated ones was "It sucks that I have to spend my time writing code to prevent abuse, instead of adding cool features." Well, we managed to add a couple cool features, but most of that time was spent writing abuse-prevention code. And this is exactly why it sucked-- I wanted to do stuff like make it so writers could edit posts, but noooooo, I had to add posting throttles instead. Foo.

Anyway, yes, it's still being promised, as it always has unto the beginning of time, as you point out. The scheme that I like most, so far, is allow authors to edit a story, and consider the edit a brand new submission, that replaces the old one. All votes and comments are gone, and we start over. I know that there will be cases where an edit loses some relevant comments, but basically, if users need to edit, it should be a major enough rewrite as to be worth that. A broken link, or a slipped HTML tag, IMO, is something for the admins to fix up-- that doesn't require a resubmission.

I also do think there should be a "cancel" option. As soon as 0.6 is out, we'll start adding these things. :-)

____
Not the real rusty
[ Parent ]

Agreed (2.50 / 12) (#8)
by Simon Kinahan on Thu Sep 28, 2000 at 09:42:21 AM EST

I think cancel would be a good thing. I'm not sure about "rewrite" as it raises issues about what to do with the comments and votes already received. I appreciate that cancel would lose the comments, but it does seem a lot simpler than schemes to preserve comments with disclaimers, or dump some comments and keep others.


Simon

If you disagree, post, don't moderate
Hrmmm. (4.13 / 15) (#9)
by Inoshiro on Thu Sep 28, 2000 at 10:01:59 AM EST

First, if you have submitted a story and want it turfed, tell the admins.  Our email addresses are in the FAQ -- we do watch and read these boxes closely.

Secondly, these kinds of features will be worked on for Scoop 0.7.  However, we are in a feature freeze right now so that bug fixes and stability is increased.  Considering the last release of scoop, 0.5, is almost 6 months old, I think it's important that the developers focus on stability before we get around to these features. If you would like the feature and know Perl, take the time to develop a patch and submit it once we get our stable branch released and start the new development branch. I know I'd appreciate this feature.



--
[ イノシロ ]
Re: Hrmmm. (2.62 / 8) (#12)
by Anonymous 242 on Thu Sep 28, 2000 at 10:24:59 AM EST

First, if you have submitted a story and want it turfed, tell the admins. Our email addresses are in the FAQ -- we do watch and read these boxes closely.

Asking one of the admins to delete a story would seem to be the obvious route.

OTOH, IMHO, that's only a temporary work around. As much should be automated as possible. Of course I do full well understand that these things take time. After all, its open source, so it will be ready when its ready and not before.

If you would like the feature and know Perl, take the time to develop a patch and submit it once we get our stable branch released and start the new development branch.

Good point. Excellent point. Perhaps I should stop wasting all my time arguing about teaching gun control to poor defenseless preschoolers and how hurricanes and the war on drugs can both wreck the distinction between hacker and cracker so that I have more spare cycles between my ears head over to http://scoop.kuro5hin.org/

Out of curiosity, though, do all kuro5hin features have to be scoop features? In other words, is there room for any k5 specific customizations to scoop?

[ Parent ]

Re: Hrmmm. (2.66 / 6) (#14)
by hurstdog on Thu Sep 28, 2000 at 11:10:16 AM EST

Out of curiosity, though, do all kuro5hin features have to be scoop features? In other words, is there room for any k5 specific customizations to scoop?

Of course there is, and lots of the customizations rusty does to k5 don't get rolled into scoop. But most do. K5 is the main testbed of sorts for scoop. If there is a memory problem, or a leak somewhere, it will show up on k5 first, since its the biggest site running scoop. Also though, lots of the changes rusty makes would be beneficial to other scoop sites as well, so he rolls them into the cvs code. Also, since scoop is GPL, I think that he kinda has to put them into scoop, if he makes changes, or at least mail the admin of scoop (him... so I guess that is kinda a moot point... anyway). So I'm rambling. I need to get to class. Thats my opinion.



[ Parent ]
That mostly makes sense. (3.85 / 7) (#15)
by Anonymous 242 on Thu Sep 28, 2000 at 11:21:21 AM EST

Thanks HD for answering my question. I find your reply very informative.

I would like to offer one slight correction concerning a comment you made on the GPL.

Also, since scoop is GPL, I think that he kinda has to put them into scoop, if he makes changes, or at least mail the admin of scoop (him... so I guess that is kinda a moot point... anyway).

IANAL, but from my reading, the GPL does not seem to require in any form or fashion that the original maintainer be notified of any changes. It does, however, require that the GPL be adhered to if the product is distributed. In other words if rusty custmizes and distributes scoop, he doesn't have to send the customizations back to scoop's sourceforge page, but he does have to include the customizations in the source code he is required to distribute if he distributes Kuro5hin.

The ten million dollar question everyone is dying to figure out is if simply putting a web site up on the internet is considered distribution according to law. Bruce Perens (and others) have argued that it isn't and hence the GPL can be circumvented through using an ASP (Application Service Provider) instead of actual distribution of a program.

[ Parent ]

Web Apps (4.00 / 5) (#24)
by rusty on Thu Sep 28, 2000 at 03:51:46 PM EST

First off, I'm the copyright holder, so technically, I don't have to release a damn thing if I don't want to. :-) Of course, if I hadn't wanted to GPL Scoop in the first place, I wouldn't have, so as far as I'm concerned, everything will always be freely available.

Secondly, I don't really have a problem with the idea that running a website is *not* distributing software according to the GPL. If I download a GPL'ed NIC driver, say, and I find that it has a major inefficiency and fix that in my local copy, but never distribute the changed source or binary, I don't have to inform anyone of my changes, or release them. This is one of the rights explicitly granted under the GPL.

If someone takes Scoop, and modifies it to run their own web site (and I mean non-trivially modifies the core code), and never tries to distribute their modified version, I think that's well within their GPL rights, in both the letter and the spirit of the license. If they get fantastically rich from their website, well, I'm happy for them. I don't think the GPL should be modified or "fixed" to account for this scenario, because IMO the license has always been intended to allow use like this.

Now, if I wrote a word processor, that could run as a web service, and someone took that and changed it and then offered the service to others, I might feel differently about that. But the only way to do that that I'm aware of is with Java, and a significant part of an app like that would have to be actually downloaded and run by the client. This would provide a solid argument that you are in fact distributing the code, and thus must release changes under the GPL.

It's a subtle difference, but I think there is a difference. Basically, if all you ever do is run it on your machine, even if a lot of people access and "use" the output of the code, it's still not being distributed. A web site like this is, at heart, just a remote access terminal into a database. I don't think this is a "circumvention" of the GPL at all. I want people to use my code. If they need to modify and customize it to make it useful to themselves, that's fine. I don't want people to be able to hide my code from others, so the GPL ensures that they can't take my code, and distribute it as "proprietary" software. If they want to keep their modifications hidden and never distribute anything, that, IMO, is their prerogative.

Then again, I've always fallen rather on the side of "weak infectiousness", so take it for what it's worth. :-)

____
Not the real rusty
[ Parent ]

Re: Web Apps (4.00 / 3) (#26)
by Anonymous 242 on Thu Sep 28, 2000 at 04:09:46 PM EST

Hi Rusty, thanks for the thought out response.

For the most part I agree with you, but I also don't think my agreement accounts for much.

The question of the day is what legally constitutes distribution. As we all, know just because something is ethically the case, does not mean that it is legally the case. Unfortunately, we will likely have to wait for a few lawsuits to come and go to find out just what distribution means.

Now, if I wrote a word processor, that could run as a web service, and someone took that and changed it and then offered the service to others, I might feel differently about that. But the only way to do that that I'm aware of is with Java, and a significant part of an app like that would have to be actually downloaded and run by the client. This would provide a solid argument that you are in fact distributing the code, and thus must release changes under the GPL.

Of course if the app server was running over vnc or some other such model, only the output of the program would be distributed.

[ Parent ]

Re: Web Apps (3.50 / 2) (#39)
by rusty on Fri Sep 29, 2000 at 05:23:50 AM EST

I think the only relevant section of the GPL is the following (Sec. 0, pp. 2):
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
That, unfortunately, would seem to indicate that accessing a program remotely, by any means, is not the same as distributing it. If you could claim that VNCing to a server running a word processor counts as "distributing", then you could easily claim that connecting to an FTP server is an act of "distributing" that FTP server code itself, and thus you must provide source for it. I don't think that holds up.

So, it appears that while in the case of Scoop, this doesn't matter much (i.e. the app is expressly intended to run on a server, has no other access method than the web, and no meaning when run outside of a many-clients->one server context), but in the word processor over VNC example, it looks like the GPL would do no good, as far as protecting the freedom of the code.

Here's hoping the clever monkeys at the FSF come up with something to deal with this...

____
Not the real rusty
[ Parent ]

Re: Web Apps (2.50 / 2) (#29)
by TheLaser on Thu Sep 28, 2000 at 05:07:45 PM EST

Now, if I wrote a word processor, that could run as a web service, and someone took that and changed it and then offered the service to others, I might feel differently about that. But the only way to do that that I'm aware of is with Java, and a significant part of an app like that would have to be actually downloaded and run by the client. This would provide a solid argument that you are in fact distributing the code, and thus must release changes under the GPL.

Well how about something like this: I, being the evil guy that I am, decide to rip off a hypothetical GPL'd word processor. I write a little Java applet that is nothing more than a virtual screen that connects to my server. I rewrite the GPL'd word processor with many spiffy new features, and have it use the Java applet. The word processor is running only on my computer, but I provide an interface to the rest of the world (full of banner ads, of course). Because I don't like the idea of anybody else copying my work and making the money that is rightfully mine, I don't release the source to the server version of the word processor. No violation of the GPL's letter because I'm not actually distributing the binary, but definatley a violation of the spirit. In fact, most of this has already been done for me. I can just use a slightly modified VNC server, with the Java applet already done.

[ Parent ]

Re: Web Apps (2.00 / 2) (#31)
by thomas on Thu Sep 28, 2000 at 05:39:39 PM EST

But the only way to do that that I'm aware of is with Java, and a significant part of an app like that would have to be actually downloaded and run by the client.

Could it not be done by having the application run on the server, and connect to the local X-server?

What is required, I feel, is an alternative version of the GPL; not replacing the existing one, but available to programmers who do not want anyone to be able to abuse their work in this way.


War never determines who is right; only who is left.
[ Parent ]

Re: Hrmmm. (3.66 / 3) (#16)
by El Volio on Thu Sep 28, 2000 at 12:00:24 PM EST

Actually, this is one of the little "holes" in the GPL. If Rusty makes modifications to K5 but doesn't distribute that binary to anyone, he doesn't actually have to make the changes public. That's one of the "gotchas" with webapps; you can change the code and make the website publicly available, but unless you distribute the binary to someone, you don't have to give them source.

IOW, I could pick up the Scoop code, make massive improvements (if I actually knew perl), and set up the Next Big Website -- and nobody would be entitled to see the source. The GPL only requires that source be available to folks who get the binaries, and that they be allowed to redistribute it freely.

Supposedly, RMS and the rest of the FSF are working on a license to fix this, but I haven't heard of any results.

And FWIW, I fully believe that Rusty & crew would make most, if not all, changes publicly available anyway.

[ Parent ]

Re: Hrmmm. (4.00 / 3) (#22)
by Inoshiro on Thu Sep 28, 2000 at 02:22:22 PM EST

As a rep of "and crew," I can say we push everything out. The CVS Scoop is the Kuro5hin scoop (less local db changes for skinability and the like) simply because rusty is 1) not someone to hide good changes, and 2) too lazy to maintain two separate branches :-)

--
[ イノシロ ]
[ Parent ]
Re: Hrmmm. (3.75 / 4) (#23)
by rusty on Thu Sep 28, 2000 at 03:31:34 PM EST

2) too lazy to maintain two separate branches :-)

I can confirm this. Yes, K5 is nearly always running the code you'll get if you check out from CVS right now. The reason the changes to K5 are always in sync with the main source is that I actually use the sourceforge CVS as a cheap way to transfer files-- I work on stuff on my home machine, check in the changes to CVS, and then cvs update on the K5 box to get the new changes. And thus, the First Virtue prevails. :-)

The only thing that isn't in the current public scoop distribution is the "Section Stories" box on the left side of the main page. Since box code can be loaded apart from library code, I just haven't gotten around to sticking it in the DB file yet. I guess this counts as a local DB change though.

____
Not the real rusty
[ Parent ]

Re: Hrmmm. (3.00 / 1) (#36)
by psicE on Thu Sep 28, 2000 at 08:42:34 PM EST

Except that if you make massive changes, it's not exactly the same Scoop that you started from, especially if you rewrote it from scratch. If you don't make massive changes, your version won't be at all popular because the official version will be constantly developed by the current crew of hackers, and yours will fall behind.

Granted, I wouldn't mind a fix of the GPL for that cause (instead of having to distribute binaries, say that if anyone has access to the code's output, via local or remote execution), but anything I write is under a BSD-type license.

[ Parent ]
Re: Hrmmm. (3.00 / 1) (#43)
by Skuto on Sat Sep 30, 2000 at 10:01:38 AM EST

Except that if you make massive changes, it's not exactly the same Scoop that you started from, especially if you rewrote it from scratch.

If you don't make massive changes, your version won't be at all popular because the official version will be constantly developed by the current crew of hackers, and yours will fall behind.

This can be a problem though, because not only the code is important but the users are too. If someone commercializes a K5 ripoff with lots of advertising and succees in drawing lots of users there, it won't matter much that the official site has updated features, because thats not the main reasons the users go there. They come to discuss and talk to other people.

In the end, this can cause the original site to starve because of a lack of 'new blood'.

I've seen this happen, and it's not pretty. I do think it is against the idea of the GPL, and if the FSF is trying to adapt it for this case, they must think so too.

--
GCP

[ Parent ]

Re: Hrmmm. (2.00 / 1) (#44)
by psicE on Sat Sep 30, 2000 at 08:24:12 PM EST

It would seem that if somebody actually used your code (which you weren't charging for per use anyway) in a large commercial site, that would still be a success. If they modified it so heavily that it no longer had the story moderation, all users can rate comments, etc. features that Scoop has now, then people would still come to Kuro5hin for exactly the reason they do now, the open environment.

[ Parent ]
Re: Hrmmm. (1.50 / 2) (#27)
by kkeller on Thu Sep 28, 2000 at 04:22:51 PM EST

So when rusty (K5) emails his changes to himself (scoop), and then modifies scoop, does he (scoop) have to email those changes to himself (K5)? Boy, I'd hate to do version control on *that* puppy....

[ Parent ]
Recursive (adj): (3.00 / 2) (#40)
by rusty on Fri Sep 29, 2000 at 05:33:35 AM EST

see Recursive.

____
Not the real rusty
[ Parent ]
See scoop site :) (3.26 / 15) (#10)
by scjody on Thu Sep 28, 2000 at 10:16:52 AM EST

Based on your experience, I posted a similar suggestion to the scoop site.

There are certainly issues with editing stories, including what to do with votes, comments, and editorial comments. I would suggest dumping all 3. Dumping votes and editorial comments should be a non issue, IMO. They simply don't apply to the new article. Comments are a tougher one, but I think they should be dumped also, especially as an article could change significantly that would make certain comments seem irrelevant or dumb. A malicious user could even submit a story and then radically change it to make a comment poster look silly. This is clearly a bad thing.

I would advocate a "retraction" option that hides the entire story and marks it as retracted. It could maybe include an option of "retract and edit" that would perform a retraction, then dump the story back into a submissions form. After editing, the user could resubmit the story as usual. This would hopefully keep hasty submissions low -- writing a good story the first time would still be easier.



A couple of other related suggestions (3.95 / 23) (#11)
by sab39 on Thu Sep 28, 2000 at 10:20:08 AM EST

I made a couple of related suggestions in this post. Basically I propose two things:
  • The ability to vote on the section as well as whether to post or dump. The dropdown would default to what the poster chose but the story would be posted to whatever section got most votes. That way there's no need to force the author to resubmit just to move a story to MLP.
  • A "Revise (-1)" option which would vote against posting, but not in favor of dumping. That way even a story with an overwhelming majority of "revise" opinions would stay in the queue; the way it is now, a story with a majority of people wanting it revised gets dumped. We've lost some great stories because of this.
See my older post for more details...

Stuart


--
"Forty-two" -- Deep Thought
"Quinze" -- Amélie

A relative newbies opinion (3.70 / 10) (#13)
by trust_no_one on Thu Sep 28, 2000 at 11:10:00 AM EST

I recently submitted my first story and it made it to the front page. I had worked on it for a while, composing it offline before pasting it into the submission form. Although it was *far* from perfect, I decided to submit it at that point in keeping with the philosophy it's better to ship something today than to keep tweaking it to death.

I then tried to actively participate in the comments process, both during the moderation period and after the story was posted. Information that I had wished I had included in the original article was submitted as a comment. While this probably isn't ideal, at least it helped me flesh out the story.

I think being able to cancel a submission is a good idea. But I'm not sure about being able to edit the submission while it's still in queue, because of the effects on voting. While I check the submission queue fairly often, I would hate to have to keep checking the same stories over and over again to see if I should change my vote as they are revised. At the very least, each modification of the story should cause the vote count to reset to zero.

I used to be disgusted, now I try to be amused

Cancel, Yes. Modify, No. (4.45 / 11) (#17)
by The Evil Troll KIng on Thu Sep 28, 2000 at 12:31:11 PM EST

I think that the ability to cancel a submission is a good idea. However, I think that being able to modify an existing story while it is being voted on is a bad idea, because the fact that someone voted for my article before I changed it doesn't mean that they would have voted for it had they seen the revised version.

I am not that familiar with the story moderation system or with K5 culture, so I could be totally off-base here, but it seems that being able to submit stories and then modify the submissions after they've been voted on would allow members of Slashdot's "Hot Grits" crowd to sneak in stuff that really shouldn't be posted. I'm not suggesting that this is likely to happen, but it seems that the possibility for this sort of abuse would exist.

If you post something, then decide that you want to modify it, you should just cancel the submission, make your changes, resubmit the story as a new article and start the story moderation over again. It seems like the fairest, most elegant solution to the problem.




==========
Thus Spake The Evil Troll King...
Re: Cancel, Yes. Modify, No. (4.57 / 7) (#19)
by ramses0 on Thu Sep 28, 2000 at 12:46:05 PM EST

Some of the suggestions have been that when an author modifies their story, all current votes are automagically cancelled, all editorial comments are removed, and all topical comments are marked "posted prior to article revision".

It's a tough issue to get right, imho.

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

Re: Cancel, Yes. Modify, No. (4.00 / 1) (#42)
by Potsy on Fri Sep 29, 2000 at 08:22:46 PM EST

I gotta say that the system would be pretty incomplete without the ability of the author modify stories. What's the point of making "editorial" comments such as "you misspelled $foo" or "your link to $foo is broken" and so on if the author cannot change it? That's what's so frustrating about the way it is now. See my previous comment for suggestions on how such a mechanism could work. Without the ability to edit stories, the queue is a crippled mechanism. Let's make it fully functional!

[ Parent ]
Yes, I believe it would be a great feature. (2.16 / 6) (#18)
by bozak911 on Thu Sep 28, 2000 at 12:32:16 PM EST

While previewing your posting can save you embarassment of formatting and spelling, being able to add to your story before it is sent to the public can save you a lot of time explaining what you are trying to get across.

Thanks.
"Show me a man with 'No Fear' and I will show you a fool." --Anonymous
Add material to end? (3.57 / 7) (#20)
by John Jorsett on Thu Sep 28, 2000 at 01:25:21 PM EST

How about allowing the author to append additional material (with an indicator and timestamp) to the end of the article? It keeps the original content but allows corrections and additional info.

Re: Add material to end? (3.00 / 2) (#30)
by Paul Johnson on Thu Sep 28, 2000 at 05:26:45 PM EST

I wondered about that, but it doesn't solve the original problem, which is an article that is on a good topic but needs a rewrite. A rewrite is a bit more than just a clarification or addendum. If a bit of extra info is needed then the author can always post a reply.

Paul.
You are lost in a twisty maze of little standards, all different.
[ Parent ]

Re: Add material to end? (none / 1) (#47)
by Sigma 7 on Tue Oct 03, 2000 at 01:37:16 PM EST

When a reader is doing a quick overview of the stories, the updates posted in the comment section may be skipped for various reasons. It would be better to append the additional information to the story itself.

However, a new story should be posted if the older one gets a major update. It will clarify the situation for the readers that view both the archives and those that view only front page stories.

[ Parent ]

Re: Add material to end? (3.00 / 1) (#45)
by lawshark on Sun Oct 01, 2000 at 04:05:45 AM EST

Additions, with a time and date stamp, would foster development of topics. Notably, this feature would allow the author to address base facts that members of the community raise in response, which the author failed to include. Multiple versions spawns confusion - in effect, people are talking about different things.

[ Parent ]
Re: Add material to end? (none / 0) (#48)
by CaseyB on Wed Oct 04, 2000 at 02:30:42 PM EST

This is in my opinion the best solution by far. Posters can clarify, update, or even apologize for the original content, but can't revise history.

Unlike most of the people here it seems, I don't think posters should be able to delete their submissions. Once they've submitted it into public domain, they should lose control of it. It keeps people accountable, and it ensures that good ideas cannot be removed for bad reasons. Also, people replying to the original story may have made significant contributions to the subject, and they should not be subject to the whims of the original poster.

If the submittor has a good reason to delete the story, he always has the option of appealing to a site admin.

[ Parent ]

YES!! EDIT< SPELLCHECK< GRAMMAR< (1.28 / 7) (#21)
by redwood on Thu Sep 28, 2000 at 02:15:30 PM EST

I think we needs* that option!
T: "how that workin out for ya?" J: "what?" T:"being clever"
Cancel is well and good but.... (3.40 / 5) (#28)
by kamakazi on Thu Sep 28, 2000 at 04:37:31 PM EST

I think it would be difficult to make an editing process that isn't confusing, and doesn't interfere with the flow of comments on an article. I think authors have a valid means of defending/correcting themselves within the comment process.

However the ability to delete your own submission would be nice, you know, that 5000 word rant inspired by the moron on the highway on the way home while you were listening to news about neighbors in Eastern Europe blowing up each others kids because their great grandparents had an argument about the color of a proper wedding dress that always seems unnecessary after you have written it and posted in in the heat of the moment.

I have yet to feed anything to the commenting machine, being new here and somewhat intimidated by the apparent desire of those who came before me to engage only in deep meaningful discussions. The ability to submit something, and if it meets severe criticism to yank it and pretend it never happened would be comforting. However the flip side is that people might yank articles because people disagreed with them, even though they might be the basis of a good discussion.

I voted for a cancel option

---

Proximity to wonder has blunted our perception and appreciation of it.
-Tim Hartnell in _Exploring_Artificial_Intelligence_on_your_Commodore_64_-
Proximity to wonder has blunted our perception and appreciation of it. -Tim Hartnell in _Exploring_Artificial_Intelligence_on_your_Commodore_64_-
Edit Option (3.33 / 6) (#32)
by Woodblock on Thu Sep 28, 2000 at 06:24:32 PM EST

My opinion is that the submission process could only have a edit feature if it reset the votes once the story was modified. Perhaps, the comments could all stay, but at least reset the votes and start fresh.
-- Real computer scientists don't use computers.
Modify? No. Append? Yes. (4.00 / 3) (#33)
by drrobin on Thu Sep 28, 2000 at 08:09:09 PM EST

I think that the author should be able to cancel his story, to re-submit it. That just makes sense, as far as providing corrections and explanations.

Modifying it while it's in the queue or on the fron page, however, can just warp a story, and has too large a potential for abuse.

What probably could work, however, would be that the author could -append- more information, corrections, etc to the end of his story. That way it wouldn't have to be resubmitted. Of course, it's still possible to abuse appending, but the original discussion is still there too.


Re: Modify? No. Append? Yes. (1.00 / 1) (#34)
by simdan on Thu Sep 28, 2000 at 08:40:55 PM EST

This sounds like a great idea. It would keep future readers from becomming confused.

[ Parent ]
Cancel yes, modify... maybe (3.42 / 7) (#35)
by grepmaster on Thu Sep 28, 2000 at 08:42:02 PM EST

Authors should in all fairness be able to cancel a post. As for modify, well maybe you should be allowed, provided you have some way of clearing the votes for the old version or something (IMHO).


(4.16 / 6) (#37)
by techt on Thu Sep 28, 2000 at 08:59:50 PM EST

Giving the author of an article the flexibility to delete the article while it is in the submission queue is a very good idea, and I don't foresee any problems with that. A spell check option would be nice, too.

Giving the author of an article rewrite access while an article is in the submission queue is an even better idea -- if done correctly. What I mean by correctly is something similar in features to CVS. Readers could then "roll back" any corrections to see the original(s) if need be. Stories would also have a version numbers and date/time stamps, of course.

User comments would be automagically tagged in the subject/author/rating box with the version number of the article they were written about. Comments which correspond to the current version of the article would have grey/blue comment boxes, comments which correspond to other versions of the article would have grey/dark grey (or other system administrator defined colors) comment boxes. Editorial comments which are not for the current viewed version of the article would be hidden, but shown if the user/reader does a "rollback" or two on the article. Each time an article is corrected by the author, the current votes will also be reset (but saved, so one can see what the votes for a "rolledback" article were.)

Of course, this would be a lot of work to implement.


--
Proud member of the Electronic Frontier Foundation!
Are You? http://www.eff.org/support/joineff.html
My suggestion (4.62 / 8) (#38)
by Potsy on Thu Sep 28, 2000 at 10:02:46 PM EST

I think this is a good idea. It's something I've been thinking about a lot lately.

Much of the time, a story will be submitted and immediately have several "change this and I'll vote for it" editorial comments posted to it.

Currently, the only option is to re-submit, and hope that people vote down the original story. And since the old version of the story is still around you have to add "(revised)" to the end of the title of your new story, just to avoid confusion.

Here is my proposal:

  • Whoever submits a story may edit it while it is still in the queue. Each time it is edited, the score is reset back to zero, and everyone can vote again.
  • When the story is edited, a revision number (or simply the word "revised") is appended to the end of the story's title.
  • Comments made to a previous version of the story remain intact, but have a short note attached to them that says something like "this comment refers to a previous revision of this story", where the words "previous revision" are a link to the previous version.<//li>
  • All previous versions of the story, complete with voting records, should be viewable through a set of links off to the side. Votes and comments only affect the latest version of the story.
  • Optional: to avoid having people change a story too often for people to keep up with it, just put a time limit on how often a story may be revised (once every few hours at maximum). I don't think an absolute limit on the number of times a story could be revised would be necessary.

Making these changes would solve a lot of problems and make the story queue into a much more interactive mechanism. Instead of "you choose the stories" it could be "you help shape the stories"!

Re: My suggestion (3.00 / 1) (#46)
by Arkady on Sun Oct 01, 2000 at 04:52:42 PM EST

Good suggestions. I think the system you're proposing should bring all the changes to article submission that I've been wanting, at least. It'd increase the database impact of the average article, but I think that'd be worth it.

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.


[ Parent ]
This might be obvious (2.50 / 4) (#41)
by grahamsz on Fri Sep 29, 2000 at 06:26:24 AM EST

But is there really any difference at all between giving the author the power to modify a story (and resetting it's vote count to 0) and only allowing them to delete the story.

If they were to delete it then they could simply repost it again with modifications (and the vote count set to 0).

As far as quick patches go it would be a lot easier to allow the author to delete any story they wrote that was still in the queue.
--
Sell your digital photos - I've made enough to buy a taco today
Edit/Cancel own story option required? | 48 comments (46 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!