Subsections


4.1 Story Selection

Scoop's original concept was to make a discussion site where all users had a say in what stories were published, instead of one where only a few editors determined what was of interest.

To this end, Scoop has the ability to allow every user to submit an article for publication, and every user to vote on which articles they would like to see published or not.

Submitted stories go into one of two queues; the ``edit'' queue is for stories that are seeking editorial feedback and are subject to editing by the author, and the ``voting'' queue is for stories that the author is satisfied with and is where the decision to publish or not is made.

All parameters relating to both queues can be changed by the site administrator, including:

All of the variables referenced in the subsections below should be in the Stories category of the Site Controls.


4.1.1 Story Queues

Permission to submit stories to the queue is given by the perm story_post (A.12.35), while permission to submit stories to the edit queue is given by the perm edit_own_story (A.12.14).

Depending on your site, you may want to allow anybody, even anonymous users, to submit stories; registered users only; or administrators only.

The voting queue is by default always turned on, but you can restrict who may vote by giving or removing the perm moderate (A.12.25) to select groups. If you are using an ``open'' queue, where any member may vote on stories, the default group (Users, generally) should have this perm; if you are using a ``closed'' queue, where only administrators may vote on stories, the default group shouldn't have this perm, but the admins, or editors, or whichever group you are using for story selection, should. Generally, the Anonymous group shouldn't have access to the voting queue, but you can do that if you find some reason for it. Users place their votes for the story, and when one of the configurable thresholds (see section 4.1.2) is reached, the story is either posted or dropped, according to the site configuration.

The edit queue is turned on by giving the perm edit_own_story (A.12.14) to the user groups who should have access to the edit queue. Stories in the edit queue are subject to change at any time, so voting in the poll and voting to post the story are both disabled. Once the author chooses to move the story to voting, the edit queue time limit set in the variable queue_edit_max_time is reached, or a certain threshold of ``spam'' votes is reached (see section 4.1.2), the story is moved to the edit queue and the author can no longer change anything.

If you are using a closed queue, ``edit categories'' may be useful. Basically, it turns off the story voting mechanism; stories are posted when one of the editors makes an executive decision to post it by editing its properties (see appendix A.1 for a description of the story edit form). Several categories are created in the moderation queue, which the editors can use to keep track of which stories are at which stage of their evolution. Edit categories only really work with a closed queue, because everything is done by editing the stories, which requires the perm story_admin (A.12.31).


4.1.2 Vote Thresholds and Auto-post

Scoop has several configurable thresholds that determine story handling while in the queue.

The simplest is the maximum time a story is allowed to stay in the edit queue, which is set using the variable queue_edit_max_time. If the time difference between ``now'' and when the story was created is greater than queue_edit_max_time, the story is moved to the voting queue. If you need to put the story back into the edit queue after the time limit, you can edit the story (as an admin) and choose the ``Set Timestamp to Now'' checkbox while moving it into the edit queue. If the timestamp is not changed, the story will not stay in the edit queue because Scoop will think it's been there too long.

The other edit queue threshold is the anti-spam vote calculation. Because a story in the edit queue can't be voted down and would stay until the time limit is reached, a malicious author can be guaranteed his spam story will be visible for the duration of the edit queue time limit--which still needs to be long enough to be useful for editing. To prevent this, there is a ``Spam'' button for a story in the edit queue, which users may click if they think a story is spam. Each user visiting the story casts a neutral vote (per account, not per visit), and each user that clicks the spam button casts a spam vote (again, per account). Once the number of spam votes set in the variable spam_votes_threshold is reached, on every subsequent vote Scoop divides the number of spam votes by the number of neutral votes and compares the resulting ratio to the ratio entered in the variable spam_votes_percentage. If the calculated ratio is greater than the variable, the story is pushed directly into the voting queue. At this point, it's generally voted down very quickly.

In the voting queue, there are several ways Scoop can decide when a story should be posted. In the following descriptions, a vote to post the story, whether to the front page or to section, is counted as a value of +1; a vote to drop the story is counted as -1; and a vote to abstain (sometimes marked ``don't care'') is counted as 0.

In the default posting calculation, Scoop sums all the votes cast, then compares them to two variables. If the sum of all votes is lower than or equal to the value in the variable hide_story_threshold the story is dropped. If the sum of all votes is greater than or equal to the value in the variable post_story_threshold, Scoop then decides if it should be posted to the front page or the section. The number of front page votes is divided by the total number of positive votes, and the resulting ratio is compared to the ratio entered in the variable front_page_ratio. If the calculated ratio is greater than or equal to the variable, the story is posted to the front page.

If the variable use_alternate_scoring is turned on, Scoop compares positive votes and negative votes to the post and drop thresholds described above separately, instead of the sum of all votes. This means that if a number of positive votes are cast that equal the number given in the variable post_story_threshold the story is posted, regardless of the number of negative votes--unless the negative votes reach their threshold first, regardless of positive votes.

There are also two possible ``auto-post'' triggers used when a story appears deadlocked in voting (this can never happen when use_alternate_scoring is turned on) and is unlikely to reach either of the thresholds. The first is based on the number of votes cast, total; the second is based on the time the story has been in the voting queue.

If the variable use_auto_post is on and the variable auto_post_use_time is off, Scoop will start its auto-post calculations when the total number of votes reaches the number in the variable end_voting_threshold.

If the variable use_auto_post is on and the variable auto_post_use_time is also on, Scoop will start its auto-post calculations when the story has been in the voting queue for longer than the number of minutes in the variable auto_post_max_minutes.

Once the auto-post has been triggered by one of the above two methods, the calculations are the same; however, if the story's current score is less than the variable auto_post_floor the following calculations are skipped and the story is simply dropped.

Scoop calculates an overall score for the story (described below) based on the votes it has gained so far, and an overall score for the comments (described below) based on the comments rated so far. These two scores are averaged, then compared to the thresholds set in several variables to determine whether or not the story posts.

Scoop scales the overall story score so the two scores are using the same scale. It assumes that normal comment rating starts at 1 and goes to the value set in the variable rating_max, so if your comment rating starts somewhere other than 1, you'll need to be careful of your threshold levels.

If the calculated average of the overall scores is greater than or equal to the value in the variable auto_post_frontpage, the story is posted to the front page. If the average is greater than or equal to the value in the variable auto_post_section, the story is posted to the section page. If the story's voting score is greater than the value in the variable auto_post_ceiling and the calculated average is so low the story would be dropped, the calculated average is overridden so that the story posts to the section. This way, stories with a poor comment score that are very close to posting normally when they hit the auto-post wall will not be dropped. The auto_post_ceiling variable should be set fairly close to the post_story_threshold variable so that the story is clearly about to post for this feature to take effect.

The overall comment score is a weighted average of the comment ratings; comments that have been rated more times affect the overall comment score more. The individual comment score is multiplied by the number of ratings for that comment to get a weighted value for each comment. The weighted values for all rated comments are then added together, then divided by the total number of ratings on all comments attached to the story. If the total number of ratings is lower than the value in auto_post_min_ratings, the variable is used instead (the ``boring story penalty''; if not many comments are rated, it must not be a very interesting story). Note that hidden comments are not counted toward either the overall comment score or the number of ratings total.

The overall story score is an average calculated from the post or drop votes cast in the voting queue. Each of the possible votes (+1 front page, +1 section, abstain, -1 hide) is assigned a numerical value, with +1 front page being worth the same as the maximum comment rating, and -1 hide being worth 1. The two other votes are assigned intermediate values based on rating_max. For each vote option, the numerical value of the vote as described above is multiplied by the number of votes cast for that option. These four values are added together, then divided by the total number of votes cast.


4.1.3 Overriding the Voting Process

As an admin, you can override the voting process in a couple of ways.

If you feel a story has been voted into the wrong place, or if there aren't enough voters yet to make a voting queue meaningful, you can edit the story using the ``Edit'' link (see appendix A.1 to familiarize yourself with the story edit form) and set the drop-down box to, for example, ``Always Display'' if you feel it should be on the front page. This is the preferred method if it's a one-time thing, or a temporary situation (such as not having enough users yet on a brand new site).

If you want to bypass the queue entirely, either for the entire site or just a specific section, for everybody or just certain groups, you can set the section permissions (see section 4.16.3 and appendix A.9 for details) to allow the appropriate groups to auto-post to either section or front page for each relevant section. This is a different auto-post than described above; this one does no calculations, but bypasses the queue entirely and automatically posts the story wherever the permissions specify. This is the preferred method if you always want to bypass the queue in certain situations.


janra
2004-03-26