[CIMC-work] Re: Automate Consensus Process
ChrisGeovanis at aol.com
ChrisGeovanis at aol.com
Mon Mar 15 00:44:32 PST 2004
whoa, 'hide' automatically sends out an email to the 'hide-ee'? who knew!
techs, the rest of us really really need a crash course in admin functions. also,
i advocate keeping admin functions simple simple simple/fast fast fast. our
trolls drop off after a while because vigorous deletes of crap train them to
quit bothering. i once again lobby for 1) training in admin functionality for
non-techs; 2) stand-alone passwords for each person willing to take up admin,
toward the goal of preserving accountability WITH privacy.
christine
In a message dated 3/14/04 1:05:15 AM Central Standard Time,
garthliebhaber at care2.com writes:
> Subj: Re: Re: [CIMC-work] Re: Automate Consensus Process
> Date: 3/14/04 1:05:15 AM Central Standard Time
> From: garthliebhaber at care2.com
> To: imc-chicago-working at lists.indymedia.org
> Sent from the Internet
>
>
>
> hmmm, I read through it. here's what I think. I think
> we're blowing the problem out of proportion. The real
> problem is monitoring the wire w/o getting burnt out.
> Increas volunteer labor pool, or make more efficient.
> Switching the delete function with the hide function as
> previously outlined may actually really help to increas
> efficiency. One would have two pages open, as one goes
> through the wire, you would click on items on the second
> page to hide.
>
> Important to remember this, though, is that a lot of the
> recent burden came from Criollo and John Locke, who
> seem to have moved on.
>
> Not to segway to much, but let me throw in that I did not
> realize hiding posts sent out emails to the poster. ahha, I
> know now, right?
>
> I also think that it's important that admins are very clued
> into what is going on with the project, and I am thinking
> that a minimal meeting attendance is necesary. Not from
> an arbitrary view, but to be in touch with what is going on.
>
> What I do like about the process that Thomas lays out is
> that we do need to lay out on paper a semblance of our
> process. We need to do this so we have a record, a
> history. But let's remember that the living history, culture,
> lies within us, as active participants. We are engaged in a
> critical consciousness, and for that you can't write scripts
> ahead of time.
>
> I don't want to say entirely no to your ideas Thomas, but
> what I think we need are people that do have a
> sophisticated political understanding within themselves
> that would allow them to participate in that capacity.
>
> I think something else I fear about such a system is that
> we would lose the personalism with one another in the
> project, the community.
>
> imho,
> g.
>
> Geo wrote:
> whoa, just when more and more of us were getting used
> to the awesome and potentially dictatorial power that the
> new code provides for 'hide' -- a pretty damned excellent
> idea grounded in direct democracy. couple things. first, i
> think our code right now is pretty much set up to let us
> use a model very similar to the Westgard model, at least if
> i'm reading admin functionality properly. problem with
> same is twofold: 1) most of us who have admin
> capabilities don't get how to use this functionality; 2) it
> takes time time time, and that is what we are all short on.
>
> what the current code does not do -- and i'm not sure
> we'd want to do -- is hold stories in a non-visible que for
> a certain period of time for editorial review. the current
> no-que situation is bad because crap goes up and has to
> come down, but good because stuff which is not crap (and
> most isn't per se) goes up right away. what tom's proposal
> suggests to me is that we should think about convening a
> stand-alone meeting for all who currently have access to
> admin privilages to really parse out the functionality of the
> new code, particularly those features (which we don't
> currently use) that mirror the functionality Tom
> describes...and start using it.
>
> there is a huge problem -- the volunteer labor pool. right
> now everybody w/admin capacity jumps on the wire or in
> admin and admins appropriately...and as their volunteer
> availability dictates. we have an enormous problem with
> getting our friends out there to even get their content on
> our wire, and i'm not sure that asking them to assume the
> additional responsiblity of managing same would work.
> seriously, alot of the stuff i post to the wire gets there via
> some query from some activist who says "can you please
> post this because i can't/won't/don't have full access to
> the internet."
>
> however, i can personally think of at least half-a-dozen
> vigilant viewers of our wire and ardent admirers of our
> project out there that will never, ever come to meetings or
> seek to join the collective but who WOULD (and effectively
> do) help monitor the wire. Bob Schwartz of the Chicago
> Anti-Bashing Network leaps to mind, for example. right
> now he calls me at work to huff when something
> objectionable comes up. is a possible solution, then, to
> empower a group of 'auxiliary' collective supporters who
> would be entrusted with helping fulfill admin functions?
> we could build in both processes and code options for
> accountability and transparency.
>
> christine
>
> In a message dated 03/13/2004 6:06:16 PM Central
> Standard Time, tom at ilmechliens.com writes:
>
>
>
> Subj:[CIMC-work] Re: Automate Consensus Process
> Date:03/13/2004 6:06:16 PM Central Standard Time
> From:tom at ilmechliens.com
> To:imc-chicago-working at lists.indymedia.org
> Sent from the Internet
>
>
>
> I have a couple of suggestions on how to make the
> consensus / hide / delete
> process a little smoother and faster. I don't know if
> anyone else is
> familiar with the two sources of my ideas: hotornot.com
> and Westgard QC
> (who shares my uncommon last name but has no known
> relation). The benefit
> in combining these is that it would entirely automate the
> selection /
> prioritization process, and take a lot of the personality
> out of it, which I
> see as a benefit. The less this is about who likes whom,
> the better.
>
> First, view the process as a categorization. Each story is
> reviewed and
> needs to be placed in a category: Great stuff goes to the
> center column.
> The vast bulk goes in the vast bulk pile. Some is dirty
> trash and gets
> hidden. Some is so bad it deserves deletion. That's
> pretty discrete input
> that could be done through a computerized process
> pretty easily.
>
> hotornot.com is a little hard to describe. Part of it is a
> matching system
> for couples; the other part is a rating system in which you
> rate a person's
> photo from 1 (not) to 10 (hot). The important thing for
> this list is that
> it has "moderators" who are given a relatively complex list
> of criteria on
> which to judge photographs and written intros. They do
> a pretty good job of
> keeping out pornography and hookers. They have
> basically the same
> discussion on hotornot as has taken place on Indymedia:
> There's a place for
> prostitutes (and Klansmen) on the Web, just not on our
> hotornot (Indymedia).
> So they have the moderators as a filtering system, but it's
> simple - they
> either say that it passes, or that it doesn't, without
> explanation.
>
> Westgard QC permits the use of multiple-track
> elimination and/or
> categorization, whereas hotornot is either all-clear or
> dead. The Westgard
> QC multi-track model works better for Indymedia, since
> there are multiple
> categories to put things in: center panel, general pool,
> hide, delete.
>
> CIMC would have moderators who would review each
> story and do their
> inputting. For a certain time after filing, a story will be in
> the review
> pool. Indymedia moderators log on and review each
> submission on a webpage
> that ends with radio buttons for various categories of
> good or bad "votes."
> Click here if it's racially offensive. Click here if it's
> concise. Click
> here if it's worker-friendly. The computer would then
> combine the data to
> place the story, using some sort of algorithm. Drafting
> the rules would
> take some time, and I am not the one to draft the
> algorithm for CIMC, but I
> think here might be some rules, by way of example (I'm
> also willing to help
> with actual drafting):
>
> If the reviewer is offended by the use of a "strongly
> disapproved word,"
> then the reviewer clicks a radio button that reflects the
> level of offense,
> anywhere from "no big deal" to "godawful." "Strongly
> disapproved words"
> would be a defined list, including the usual ethnic,
> religious, and gender
> words. You might have situations like a hip-hop reporter
> who refers to
> Jesse Jackson as "my nigga." The sex columnist who
> writes about "fags." Or
> a story on guns says something about "that bitch Janet
> Reno." The presence
> and degree of offensiveness is contextual, and whether
> the particular
> reviewer takes offense would be the measurement.
>
> Center panel material is still by consensus, but there's no
> longer any
> emailing around to get it. There's a time limit for input,
> and anyone who
> gets their data in within the time limit determines what
> goes on the center
> panel. There's a radio button for "center panel
> nomination," and if any
> Indymedia reviewer doesn't click that button, then the
> story doesn't go
> there. You could also have a default option, in which, if
> no new story gets
> placed there for a certain time, then the highest-rated
> story gets placed
> there instead of a consensus story. Or all stories getting
> a rating over a
> certain number or ratio.
>
> In order to make sure the system is working according to
> Indymedia
> standards, you collect the data on which moderator rates
> what on which
> stories. Moderators agree not to be anonymous, at least
> to the extent of
> having their judgments recorded. Then you monitor the
> moderators /
> reviewers in person. This is where the email and face-to-
> face comes in.
> "Bob, no one else found a racially-charged word in this
> article. Why did
> you give it a bad vote for racial offensiveness?" It doesn't
> mean Bob's in
> trouble, since he may just have a bigger or more recently
> updated vocabulary
> than the rest. It's a chance to review the rules to see if
> they create the
> right result. If everyone is honestly following the same
> rules, there will
> largely be agreement on the ratings. It just allows you to
> track down
> stealthy Nazis who get in and give a bad rating to
> everything except Nazi
> stories.
>
> The end result would be that this selection and
> categorization process would
> become largely automated, leaving the current workers to
> step up a level -
> managing reviewer / moderators, instead of doing all that
> editing work
> themselves. Then there could be an effort to make sure
> that the moderator
> pool matches Indymedia's goal clientele. We could invite
> desireable people
> to become moderators, say, board members of
> organizations we like, who would
> commit to logging on and reviewing ten stories each day
> (or ten a week -
> whatever). This allows for a community outreach and
> publicity program for
> Indymedia.
>
> Thoughts, comments, praise, rotten vegetables?
>
> Yours,
> Tom
>
> _______________________________________________
> Imc-chicago-working mailing list
> Imc-chicago-working at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-
> chicago-working
>
>
>
>
>
> Stop baby sea turtles from being crushed!
> http://www.care2.com/go/z/11745/1008
> _______________________________________________
> Imc-chicago-working mailing list
> Imc-chicago-working at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-chicago-working
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.indymedia.org/pipermail/imc-chicago-working/attachments/20040315/808ddae4/attachment-0001.htm
More information about the Imc-chicago-working
mailing list