Thoughts For The Future
From Barbelith
Heya, here's the stuff that I'd love it if you could have a look at doing. Some of it's pretty simple, and some of it is less so...
// LOGIN MECHANISM: I was wondering whether or not you could change the login mechanism. Basically at the moment they just have to type in a user name and a password and they get an account created for them. For some reason we never made them use a legitimate e-mail address and we never checked it. I can't remember why this was, but I'd really appreciate it if we could add that functionality. So standard stuff: register.php When people have submitted it, return a page that says something like "Now check your e-mail inbox for a confirmation e-mail. You will need to follow the instructions in that e-mail to finish your registration and start posting." Send them the e-mail with a link in it that they have to click to confirm it's a real e-mail address and that they are in fact real people. No multiple user names from the same e-mail address though. One e-mail address per person.
// SEPARATING OUT THE MESSAGES AND MOD ACTIONS At the moment they're both on the same page and they're treated the same way. What I was thinking of instead would be that if you clicked on the number of jobs you had to do, you'd just get taken directly through to the first one to vote on and when you had voted on it, you'd get taken straight through to the next one. When you'd finished, you'd be pushed back to the front page. It might be worth adding a 'skip' button that moved you to the next one in the queue as well for those requests that they're not sure about. I'd say putting in an abstain button would be a better option, except that we can't have everyone abstain as we wouldn't get any of the more complicated ones done.
I think this is a better model for a range of reasons: 1) there are two links that get you through to these pages and I think they should go to different places 2) when people currently vote on an action it takes them back to the list view and then they have to click through to another one. That's fine when there are only a few mod requests, but not great when someone pushes through 200 in a day (this has happened).
Skipped moderation requests should still show up in their list of mod actions to do when you've run through all the pre-existing actions ...
// BUILDING A SEMI-PERMEABLE MEMBRANE AROUND BARBELITH - NEW MEMBERS BEING PRE-MODERATED BY THE OLD ONES
Right. The concept in a nutshell is new members' messages being pre-moderated by existing members. There are a variety of problems with this as an approach (as far as I can tell), many of which depend upon the speed of moderation by the board's existing community. I'm going to try and be as precise as I can about what I'm thinking of, but there are loads of places where I'm a bit unsure about whether it would work, and if you have ANY thoughts, then please god don't keep them to yourself.
Junior Members ______________
The first thing we need to do is create a new class of user which I'm going to provisionally call a "Junior Member". This is the default class for people who sign up to the board, but it's also a class that people can be made later on by moderation action (more on this later).
Junior members should have different posting limits than full members - this limit should be settable in the init.txt file and initially it should be five posts per day. Junior members should be able to see the New Topic button, but when they click on it they should be told that they are not able to start threads because they are new (at least initially - many of these things might turn out to need nuancing, so it would be really cool if this was turn off-and-on-able in the init.txt file - this is not crucial though). Junior Members should also be able to see the Add Your Reply button, and when they go to that page they should be given a piece of preamble text that I'll write that explains the process to them and then the normal posting stuff. If you could make it so that I can write some preamble text that showed up instead for everyone else that would be ace. [Do you have any thoughts on whether they should be able to read/send private messages?]
When a user becomes a Junior member, the board should record the date at which this occurred (in a separate field from the date_create field), and also create some kind of running score-card for them (one field or several, don't know what you think).
When a Junior Member posts a reply to a topic, it should NOT show up on the board. Instead it should be added to some kind of moderation queue. I can think of various ways we could do this but you're basically the expert, so I'll bow to your expertise. One way could be that we could just put the posts directly into the barb_posts database and add a new field 'approved' or something (we could even just start them off as 'deleted' and just undelete them when appropriate), with another table keeping track of whether they should be made public or not. Another way would be to have a distinct table like you have made for moderation actions and keep everything in there, only squeezing it into the posts table when necessary. Up to you, really.
Not only should the junior member's reply not be displayed on the board, it should also not update information about the thread (like last posted-to time or the number of posts in the thread). It should also not say that they've posted anything on their user profile. These things should happen at the time at which the posts are approved and appear on the site (but they should use the time they were originally posted, rather than the time that they were approved). [NOTE - NOT SURE ABOUT THIS BIT - THOUGHTS / SUGGESTIONS WELCOME - BUT BASICALLY BIT NERVOUS ABOUT CONVERSATIONS IN WHICH LOTS OF PEOPLE ARE REPLYING VERY QUICKLY AND SUDDENLY A NEWBIE'S CONTRIBUTION APPEARS IN THE MIDDLE OF LOADS OF OTHER POSTS AND NO ONE SEES IT).
Approval interface: ___________________
Ok - so the posts are in the database somewhere, but they're not on the site yet. So now we get the approval mechanism. Basically I'd like ideally the 'approve junior member post' action (or whatever we call it) to be an action that you vote on like any and all others except these ones would be visible to normal users, moderators and admins rather than just moderators and admins. So normal members would now see 'you have X jobs' at the top of the screen - they just wouldn't see all the other moderation actions, only approvals. Junior members should still not see this.
Limits on new-user-approvals - basically there should be a limit on the number of new user post approvals that any one person should do in a day (and hence be able to see in their queue). I would like this limit to be settable in the init.txt document but start off initially as ten if possible. There are lots of reasons for this, but the main reason is that just having a list of all of them at any given point would make the whole thing seem really volatile and overwhelming to most users. Normal users should NEVER come in and see more than '10 jobs to do', they should be able to come in, run through them quickly and not worry about it at all until the next day.
If it's not possible to put the user approval stuff in the same queue as the other moderation actions, that's ok - we'll put another link below the first one. But if it was possible that would be awesome, because it would make the whole moderation process much easier to communicate to people.
So basically the approval process should be just like moderation actions at the moment, only visible to normal users and with a limit on the amount they can see in any given day. When you click on the link, you should be presented with a screen that has the post on it and information about it and the equivalent of a 'yes' / 'no' pair of buttons. Same as normal.
Initially it should take three approvals to put a post onto the site and one to stop it happening. But it would be good if both of those figures were changeable in the init.txt document.
For each post that is approved the junior member's scorecard should get an extra point. For each that is rejected they should either get no points or should lose a point. [Cal - Any thoughts from you here?]
If a post is rejected, could we send them a private message with the text of their post in it and a brief message at the top advising them to read the FAQ etc. Something like "Unfortunately it has not been possible to post your message to the thread BADGERS BE HERE. A random selection of current Barbelith users checked your post to see whether it "
Junior Members to Full Members: ________________________________
Basically every time a Junior Member posts something the board should check the score-card and the date they became a junior member. IF the score card is over a defined number AND the date is a defined period from the current date, then they should be made a full member. Any subsequent posts they make should be with the full member interface.
Moderating people down to Junior Member:
________________________________________
The other aspect to this is that I think we should allow moderators to propose a moderation action to make people Junior members again. The benefit here is that if someone trolls for ages then we have another form of combat rather than simply
<a href="/msg_send.php?msg_to=<? echo urlencode($profile_row[displayname]); ?>" class="normal">click here to send</a>
// MOD ACTION VOTES AND VETOS (LESS IMPORTANT) At the moment as far as I understand it people can either vote yes or no. A yes vote is added to the total number of votes for an action and if it reaches a set number then it is acted upon. A no immediately vetos. What I'd like is to be able to set more flexible voting, so that some things need more than one no vote to be cancelled. This has basically emerged because we've added loads of moderators to make the ratifications happen quickly (more people online means faster ratification or otherwise on moderation actions), but some of them are a bit naive and will vote no for things that should be voted yes for. Basically I need a BIT of flexibility when it comes to compensating for dumbasses. So as far as I can tell all this information is held in includes/actions.txt and each one is defined by having a function name, a number of votes to perform the action and a name that members of the board see. What i'd like to do is add another defining characteristic in there which is the number of votes it would take to cancel each action. Mostly it's still going to be one.
