Discussion:
Some initial thoughts
(too old to reply)
Kim van der Linde
2006-09-18 13:42:53 UTC
Permalink
Hi All,

Some initial thoughts after reading much of the stuff.

1. anonymous editing. This is only a problem at Wikipedia because it
facilitates vandalism and insertion of nonsense, but some anonymous
editors are adding real good content. The problem comes with the fact
that what they add is immediately visible for the world, and as such,
becomes a magnate for vandalism. If we get a level of editorial control
(approve flagging), the vandalism will never reach the published pages.
As such, we are trying to do a double kill on vandalism etc.

2. Real world names. Nice, but unnecessary. For the editors I can see
this requirement, but along the same line as for anonymous editing,
double kill of a problem, and potentially chasing people away.

3. Progressive fork. In my opinion, probably the worst idea possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an incentive for
citizendium editors to get as soon as possible as many as possible pages
updated and to par with our quality standards.

As an added motivation, if citizendium gets soon the benefit of the
doubt with the main public, we effectively become the content provider
for Wikipedia, with the costs of additional infrastructure (wikipedia
runs 100+ servers?) for what is effectively not our work, with content
that could be seriously substandard.

4. Copyeditors. Copyeditors are of paramount importance. Many academics
are good in writing academic texts, which is different from writing for
the general public. As such, we will need talented copy editors who like
to improve the general reading quality of articles, or just to flag
where things are difficult to follow. Good copyeditors should IMHO get
the freedom to copyedit pages within specific fields that they
understand, without having to run them along the editors all the time
(more like a afterwards check).

More to follow....

Kim
--
http://www.kimvdlinde.com
Darren Duncan
2006-09-21 03:40:44 UTC
Permalink
This message is mainly a reply to an excellent point raised by Kim
van der Linde ("Some initial thoughts"), but it also thematically
follows up my "a truly rigorous/accurate resource process design"
message.
Post by Kim van der Linde
3. Progressive fork. In my opinion, probably the worst idea possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an incentive for
citizendium editors to get as soon as possible as many as possible pages
updated and to par with our quality standards.
I couldn't agree more with this. And if the principle behind it were
implemented, that would solve quite a lot of issues that have been
raised by various people.

Citizendium should be its own distinct entity where *all* of the
content it stores should be vetted, or at least each content item
should be manually given the once-over by whomever submits it. No
detail or section should be added that wasn't added intentionally on
its own merits. If a visitor sees any content on our site, they
would know that we stand behind it, notwitstanding that anything
could still possibly have errors.

A mass copy of Wikipedia is the wrong approach to take for several
reasons, some of which reiterate Kim's comments:

1. It needs to be in black and white as to which content we stand by
vs which content we have no opinion on due to being copied. Nothing
spells that out more than a big sign reading "article doesn't exist
in Citizendium yet, meanwhile here is a helpful link to an
appropriate Wikipedia article". (And that link has a target=blank so
Citizendium remains open in their browser when they go to Wikipedia
for that article, and they don't forget about us once there.)

Simply coloring text differently depending on ours vs theirs, or
having 2 versions of a page (each of which some of us have
suggested), does not stand out at all, and 99% of the public won't
notice it, so they will just think that most of our content is bad,
or is "the same" as Wikipedia; and since the latter has (for now)
better servers, the public will go there instead as we haven't really
differentiated ourselves.

2. A database which is initially small (because it only has our own
vetted content) requires less resources to maintain and serve. We
can start out effectively with a smaller initial investment in
servers. It gives us more time to scale up and work through kinks in
our system, and it better survives any "slashdot effect". We only
really get hits on our server for articles we have vetted, and for
the 99% plus that we haven't, we don't get most of the hits.

3. The good content stands out more, and so any experts will feel
more justified or rewarded for contributing, since their goodness
won't be lost in a sea of mediocricy. Similarly for non-expert
editors.

4. Bringing in content piecemeal also allows us to rethink how it is
organized, so we can have a second chance to pick good article names
or otherwise organize tags or wider topics for articles differently,
where we want to.

In particular, we could address from the start about dealing with
homonyms, and go right from the start such that *all* normal articles
have urls like "Foo (Bar)", and such that *all* urls with just "Foo"
are disambiguation pages, even if there is only one meaning; there
could be others later, so we should think ahead and design to scale,
and that is one way to do it.

If we do deal with article urls that way from the start, then all
links can initially be "Foo (Bar)" and hence no one clicking on an
older url is likely to come to a disambiguation page due to a "Foo"
being split up.

5. We can and should be treating Wikipedia as a SOURCE, just like
anything else, and not privilege them above other sources by us being
a "fork".

Though that's not to say that Wikipedia can't be a source that we
copy text from more or less verbatim, since its and our license
allows us to do so. But it would still be manual, though our techs
could have utilities to make common copying operations easier like a
"copy from the Wikipedia article at this (possibly different) article
url" feature that inputs directly into an editing form.

Wikipedia should explicitly be an EXTERNAL source, like everything
else, and be cited in the sources section like anything else. This
also helps our visitors get a more accurate impression of how we know
what we know ... because Wikipedia (external) and Foo (external) and
Bar (external) say so.

It is a lot easier to treat Wikipedia as a source if we aren't a
"fork" of them.

Incidentally, for the inevitable copying back, Wikipedia should also
consider Citizendium to be a source of theirs, in a similar fashion
to what I prescribe.

6. This approach lets us be multi-national right from the start,
rather than just starting off as a clone of the English Wikipedia
data. In the spirit of free and open-source software (FOSS), each of
us will "scratch our own itch", and want to write or edit articles in
any language we feel like, so the technical capacity should be there
from the start.

While there may have been an argument for English-only in Larry's
proposal as a matter of simplicity, I don't see that being necessary
when we're not copying Wikipedia whole-hog from the start. So we can
be multi-national *now*.

On a related note to #4, I suggest having the multiple languages
integrated in a single database and interface, rather than having a
separate "site" for each language.

That is, users can choose a language from a menu when they enter, but
the only distinction between what they get for doing so would be what
language the Citizendium menus and buttons and standard components
are in, as well as a vote for preferred language of content.
Moreover, we only need one internet domain, and a language choice can
be part of the path; eg: http://citizendium.org/en/whatever .

Similarly, all articles in the database should be inherantly
multi-lingual, in a fashion reminiscent to multi-lingual software,
taking for one example how Mac OS X works. For each article (the
"Foo (Bar)" mentioned in #4), exists one or more "language
resources", each of which is a version of the article written in one
language. A visitor by default sees the version in their chosen
language, but if one doesn't exist, then can be given the option to
either go to the version in a different language, or add a
translation (sort of like adding a new article), or alternately see
the external Wikipedia version in that language.

The idea is that there should be a clear symmetry between all
language versions of an article, where they contain the same info,
but in different text, and also, that they have identical urls save
for a language component. In addition, article elements like images
that are language agnostic can be applied to the collection as a
whole, and appear in each version. A key point is that it should be
easy to tell for any given article which translations exist.

Note that, in real life, these will likely be out of sync, and
regardless there should be a pseudo-source-citing record that says
whether a particular language resource is the original expert-written
article, or whether it is a translation of a different resource, and
which one. Then people looking at any particular language can follow
the source chain from our translation to our original and so on.
Translators can make mistakes. And in any event, this citation would
include when the translation was done, so we know how accurate a
version is relative to its other-language original. Of course, it
can go both ways, with some edits being originally done in one
language B then translated to A, while other parts go A to B. It
needs to be appropriately marked.

Now, assuming this is different from how Wikipedia operates, this is
another advantage of starting from the bottom as I suggest, so the
pieces can be appropriately put in place.

It also perhaps stands to reason that, while any version can be an
original, it would be recommended to do all primary edits in the
English version when the editor understands enough English to
reliably do so, so to make some things simpler; English is the
nearest to a universal language that we have.

In regards to the point one may raise about how the same article
names may be different in different languages (some are, some
aren't), we can still set up things technically so that the right
things happen.

7. I had other reasons, but they slip my mind at the moment ... more
later then.
Post by Kim van der Linde
1. anonymous editing. This is only a problem at Wikipedia because it
facilitates vandalism and insertion of nonsense, but some anonymous
editors are adding real good content. The problem comes with the fact
that what they add is immediately visible for the world, and as such,
becomes a magnate for vandalism. If we get a level of editorial control
(approve flagging), the vandalism will never reach the published pages.
As such, we are trying to do a double kill on vandalism etc.
2. Real world names. Nice, but unnecessary. For the editors I can see
this requirement, but along the same line as for anonymous editing,
double kill of a problem, and potentially chasing people away.
Following the principle of saying just what we actually know, I
propose that real world names not be a strict requirement, but a soft
requirement and/or a strong recommendation.

One reason is that people can always lie, and pretend to put in a
real name when they actually aren't. Second is that there is
sometimes a legitimate reason for someone to hide whom they are, such
as if what they say will get them arrested or killed by an oppresive
regime.

All that said, this is what I propose:

1. Everyone who adds or edits anything on Citizendium must have a
named account on Citizendium. No one can add or edit anything
without logging in.

2. When someone creates a Citizendium account, they supply a Public
Name, which is what someone is known by on the system, regardless of
whether it is their real name or not (people will use their real name
usually by recommendation), and an email address, which has to be
verified to activate the account (admins may need to contact them) by
sending an auto-message to it with some code, so that we know it is
their address and they spelled it correctly. Then they provide a
password, and separately there are various profile-type fields where
they can put in their real name and CV and whatever.

3. Like a typical article, an account has its own corresponding page
with all the profile-type details on it, and it can include its own
cited sources that refer to the person's web site or otherwise
external proof that they are who they say they are.

4. All Citizendium add/edit/etc activity is attached to the account,
for crediting and by way of that to their CV or whatever.

5. Of course, someone could still lie about who they are, but what
info they provide or how verifyable it is will contribute to the
validity of any changes they make to the system, and what changes
they make are tracked to the account. Generally speaking, the public
or other systems can put more weight on one account than another, for
determining experts et al, based on this proof attached to the
accounts.

So, that's about that for today.

I remind you, as mentioned in my other posts, that I have thought
about these matters for a *long* time (since 1998 at least) as I work
towards my own system that implements such things, possibly to
supplant wikis some day.

Consideration and feedback appreciated.

Thank you. -- Darren Duncan
Peter Evans
2006-09-21 11:57:34 UTC
Permalink
Post by Kim van der Linde
3. Progressive fork. In my opinion, probably the worst idea possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an incentive for
citizendium editors to get as soon as possible as many as possible pages
updated and to par with our quality standards.
I strongly agree. Have there been any arguments against this? (I'm new to this
list and wouldn't know.)
Freddie Salsbury
2006-09-21 12:04:37 UTC
Permalink
I'm working through the list topics, so this might be redundant.
But couldn't this be handled by a tagging mechanism.

Have headers: "Unchanged from Wikipedia", "Edited, but unverified" "
Verified" (Maybe Verified by Subject Editor XXXX) for different
sections, and also have different colors (with a light background)
for each different tag.
The colors would make it clear the extent to which an the article is
verified or edited, and the headers would explain the colors.
Post by Peter Evans
Post by Kim van der Linde
3. Progressive fork. In my opinion, probably the worst idea
possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by
including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an
incentive for
citizendium editors to get as soon as possible as many as
possible pages
updated and to par with our quality standards.
I strongly agree. Have there been any arguments against this? (I'm new to this
list and wouldn't know.)
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
Zachary Pruckowski
2006-09-21 12:36:05 UTC
Permalink
My immediate concern would be getting people to notice that. I
hesitate to say that people are dumb, but the fact is that they're
there for one thing: the info. They probably won't notice the
background color. If we have a few frames and the exact WP page for
unchanged pages, then move all the WP stuff to our /dev pages, we're
in good shape, because we "normal contributors" can pick them apart
as we get around to it and have experts sign them off. So it might
be months or years before we're 100% Citizendium-branded content, but
if we do it right, we can get the major articles (for academics) like
the science and history and math ones done long before that, and only
have the stragglers be "South Park Episodes from 2005" or something.

Zach Pruckowski
UVA CLAS 2009
Post by Freddie Salsbury
I'm working through the list topics, so this might be redundant.
But couldn't this be handled by a tagging mechanism.
Have headers: "Unchanged from Wikipedia", "Edited, but unverified" "
Verified" (Maybe Verified by Subject Editor XXXX) for different
sections, and also have different colors (with a light background)
for each different tag.
The colors would make it clear the extent to which an the article is
verified or edited, and the headers would explain the colors.
Post by Peter Evans
Post by Kim van der Linde
3. Progressive fork. In my opinion, probably the worst idea
possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by
including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an
incentive for
citizendium editors to get as soon as possible as many as
possible pages
updated and to par with our quality standards.
I strongly agree. Have there been any arguments against this? (I'm new to this
list and wouldn't know.)
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
Freddie Salsbury
2006-09-21 13:20:13 UTC
Permalink
I agree with you on this point. More charitably, if the subject is
interesting enough a reader might get a little too preoccupied to
notice a color change, or even if they did without a legend it might
be difficult to figure out what the colors means.
So I specifically -- and several people have had similar ideas on
this list already -- something like the following:



Article Zeta
off to the side White background indicates articled verified by
editor
Light Green indicates Unverified and unmodified from
Wikipedia as of XX/XX/XX
Light Blue indicated Changed but unverified


Section Alpha
Verified by Dr. Y

Text

Section Beta
Unmodified from Wikipedia
Text (Light Green background)


Section Gamma
Edited but unverified
Text (Light Green background)
Post by Zachary Pruckowski
My immediate concern would be getting people to notice that. I
hesitate to say that people are dumb, but the fact is that they're
there for one thing: the info. They probably won't notice the
background color. If we have a few frames and the exact WP page for
-------------- next part --------------
HTML attachment scrubbed and removed
Zachary Pruckowski
2006-09-21 13:49:02 UTC
Permalink
I think that's a good idea, but I'd think the main "public" pages
should be an all-or-nothing thing, especially if we have /dev pages
(I would rather that name not sound so "computer sciencey", maybe it
should be /draft). If we move a WP page over, maybe we should do it
once we've at least had someone go over the whole thing and check it
off, and then just link to the WP page until we've done that. I do
think that your method could work too.

I think the idea of "verified by" is a good one. I think we want a
professor's/expert's name on the page if they're responsible for that
page, both to entice them and to give it some credibility. If the
page on article Zeta has "verified and moderated by Professor Blank,
University of College" on it, then the page has someone willing to
keep up with it. If a page is regularly verified/moderated by 1-2
professors, we're in good shape. Something like [[Evolution]] or
[[Gravity]] which will likely see contributions from a lot of experts
(4+) could go to "Edited and verified by the Science expert staff"
with a link to that list.

Zachary Pruckowski
UVA CLAS 2009
Post by Freddie Salsbury
I agree with you on this point. More charitably, if the subject is
interesting enough a reader might get a little too preoccupied to
notice a color change, or even if they did without a legend it
might be difficult to figure out what the colors means.
So I specifically -- and several people have had similar ideas on
Article Zeta
off to the side White background indicates articled verified
by editor
Light Green indicates Unverified and unmodified from
Wikipedia as of XX/XX/XX
Light Blue indicated Changed but unverified
Section Alpha
Verified by Dr. Y
Text
Section Beta
Unmodified from Wikipedia
Text (Light Green background)
Section Gamma
Edited but unverified
Text (Light Green background)
Post by Zachary Pruckowski
My immediate concern would be getting people to notice that. I
hesitate to say that people are dumb, but the fact is that they're
there for one thing: the info. They probably won't notice the
background color. If we have a few frames and the exact WP page for
-------------- next part --------------
HTML attachment scrubbed and removed
Kevin Winter
2006-09-21 19:04:31 UTC
Permalink
I think that's a good idea, but I'd think the main "public" pages should be
an all-or-nothing thing, especially if we have /dev pages (I would rather
that name not sound so "computer sciencey", maybe it should be /draft). If
we move a WP page over, maybe we should do it once we've at least had
someone go over the whole thing and check it off, and then just link to the
WP page until we've done that. I do think that your method could work too.
I quite agree with this. As a further suggestion, why not (as already
suggester by sanders) import every wikipedia article, but directly
into draft/dev. This will help along with Kim's suggestion not to
start with unverified content. By dumping wikipedia's article into
draft, the experts can go over articles that may _already_ be
factually true and sign off on them. This would be a LOT faster than
writing a brand new article from scratch. It provides CZ with a lot
more flexibility than a mass import to public, or a blank slate.
I think the idea of "verified by" is a good one. I think we want a
professor's/expert's name on the page if they're responsible for that page,
both to entice them and to give it some credibility. If the page on article
Zeta has "verified and moderated by Professor Blank, University of College"
on it, then the page has someone willing to keep up with it. If a page is
regularly verified/moderated by 1-2 professors, we're in good shape.
Something like [[Evolution]] or [[Gravity]] which will likely see
contributions from a lot of experts (4+) could go to "Edited and verified by
the Science expert staff" with a link to that list.
This is an excellent idea. +1

~Kevin
--
Open Source, Open Mind
Kim van der Linde
2006-09-21 19:12:22 UTC
Permalink
Post by Kevin Winter
I quite agree with this. As a further suggestion, why not (as already
suggester by sanders) import every wikipedia article, but directly
into draft/dev. This will help along with Kim's suggestion not to
start with unverified content. By dumping wikipedia's article into
draft, the experts can go over articles that may _already_ be
factually true and sign off on them. This would be a LOT faster than
writing a brand new article from scratch. It provides CZ with a lot
more flexibility than a mass import to public, or a blank slate.
Just some thoughts:
1. Do we want ALL Wikipedia articles?
2. If so, do we want all Wikipedia articles under their Wikipedia names?

A one time copy-paste action from the wikipedia article is all what is
needed to get started (if that is a good starting point to start with in
the first place). Just my 2 cents...

Kim
--
http://www.kimvdlinde.com
Zachary Pruckowski
2006-09-21 19:44:09 UTC
Permalink
If we do it all at once and stick it in ARTICLE/draft (I assume
that's the official proposed name for it now), then we make it easy
to get articles ready for people who aren't as wiki-savvy. If all we
have to do is tell experts to start with the /draft versions of the
articles in their fields and look them over, that will help a lot.

The downside is that it could be weeks or months before we cover all
the science/history/math and other factual articles, and upwards of a
year before we get to some of the cultural stuff. That means we lose
a lot of edits on Wikipedia on those articles (which may or may not
be a bad thing, but I'm thinking it is). Can we do like wikinfo and
have an automatic script import articles whenever someone clicks a /
draft page we don't have?

Zachary Pruckowski
UVA CLAS 2009
Post by Kim van der Linde
1. Do we want ALL Wikipedia articles?
2. If so, do we want all Wikipedia articles under their Wikipedia names?
A one time copy-paste action from the wikipedia article is all what is
needed to get started (if that is a good starting point to start with in
the first place). Just my 2 cents...
Kim
-------------- next part --------------
HTML attachment scrubbed and removed
Kevin Winter
2006-09-21 20:25:15 UTC
Permalink
Post by Kim van der Linde
1. Do we want ALL Wikipedia articles?
2. If so, do we want all Wikipedia articles under their Wikipedia names?
A one time copy-paste action from the wikipedia article is all what is
needed to get started (if that is a good starting point to start with in
the first place). Just my 2 cents...
This is a good point. The downside is we may not have an article for
foo or bar if Editor Fred doesn't think of the topic. We might (at
the very least) want to grab an article title list from WP and then
trim it down to what we want. Keep the mass import into ARTICLE/DRAFT
and then have the actual article a blank page (until an editor decides
to keep, reject, or move). Then the editors can go in and check if we
even want to keep an article (such as one on Vegeta or Mewtwo).
Hopefully that will keep us from forgetting a topic, while allowing us
to easily rename and reject unsuitable content. (By unsuitable, i mean
frivolous, not as in censorship).

~Kevin
--
Open Source, Open Mind
Ricardo Gladwell
2006-09-21 14:22:03 UTC
Permalink
Post by Darren Duncan
Post by Kim van der Linde
3. Progressive fork. In my opinion, probably the worst idea possible.
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an incentive for
citizendium editors to get as soon as possible as many as possible pages
updated and to par with our quality standards.
I couldn't agree more with this. And if the principle behind it were
implemented, that would solve quite a lot of issues that have been
raised by various people.
I agree: importing articles on a case-by-case basis seems much more
reliable to me.
Post by Darren Duncan
Post by Kim van der Linde
1. anonymous editing. This is only a problem at Wikipedia because it
facilitates vandalism and insertion of nonsense, but some anonymous
editors are adding real good content. The problem comes with the fact
that what they add is immediately visible for the world, and as such,
becomes a magnate for vandalism. If we get a level of editorial control
(approve flagging), the vandalism will never reach the published pages.
As such, we are trying to do a double kill on vandalism etc.
As I understand it, anonymity is still allowed in the guise of
registered but unidentified users, or 'citizens.' Anonymous user's are
denied authoritative editor status but they may still edit articles and
work with identified editors.
Post by Darren Duncan
Simply coloring text differently depending on ours vs theirs, or
having 2 versions of a page (each of which some of us have
suggested), does not stand out at all, and 99% of the public won't
notice it, so they will just think that most of our content is bad,
or is "the same" as Wikipedia; and since the latter has (for now)
better servers, the public will go there instead as we haven't really
differentiated ourselves.
Citation and verifiability should be an important part of Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
Post by Darren Duncan
Post by Kim van der Linde
2. Real world names. Nice, but unnecessary. For the editors I can see
this requirement, but along the same line as for anonymous editing,
double kill of a problem, and potentially chasing people away.
Following the principle of saying just what we actually know, I
propose that real world names not be a strict requirement, but a soft
requirement and/or a strong recommendation.
I don't think the price of giving up some anonymity for some trust is
unreasonable. What is more requiring use real names is it makes editors
verifiable, and not just articles. When someone reads a Citizendium
article not only can they check the sources, but they can look up the
editors of the article and verify these individuals, research their
previous work, verify their qualifications, etc, all of which I feel
would be crucial in building trust and authority for Citizendium.

In this case, the 'soft' identity requirement you outlined is identical
to "registered but anonymous."

Kind regards...
--
Ricardo Gladwell
http://gladwell.selfip.com/photos/
Derek Lyons
2006-09-21 20:38:57 UTC
Permalink
Post by Ricardo Gladwell
Citation and verifiability should be an important part of Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
It is no more possible to cite and support every passage, phrase, and
word in an article than it is to travel to the moon on the wings of
giant swans. It is utter lunacy to believe this is either possible,
or desireable.

When you read a scholarly work, this is not done. When you read a
popular work, this is not done. Where did the belief arise that this
is should be done for an online compendium (or encyclopedia)?

D.
Freddie Salsbury
2006-09-21 21:48:45 UTC
Permalink
I do agree that providing citations for "every passage, phrase and
word" is impossible, but scholar works do (or should) provide
citations for every significant point that isn't new and supported by
data. Wikipedia has become much better in the last ~6 months or so,
but requiring, or strongly encouraging a high level of citation would
be a significant improvement.

Fred
Post by Derek Lyons
Post by Ricardo Gladwell
Citation and verifiability should be an important part of
Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly
cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
It is no more possible to cite and support every passage, phrase, and
word in an article than it is to travel to the moon on the wings of
giant swans. It is utter lunacy to believe this is either possible,
or desireable.
When you read a scholarly work, this is not done. When you read a
popular work, this is not done. Where did the belief arise that this
is should be done for an online compendium (or encyclopedia)?
D.
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
Derek Lyons
2006-09-22 16:51:43 UTC
Permalink
Post by Derek Lyons
Post by Ricardo Gladwell
Citation and verifiability should be an important part of Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
It is no more possible to cite and support every passage, phrase, and
word in an article than it is to travel to the moon on the wings of
giant swans.
It is inherent in the passage quoted above.
I only suggested we colour those parts of an article that have not been
cited or verified not that every part need citation. Part of the system could
include identifying those parts of an article that do not need citation.
Which means, to me, that it must start colored (uncited) - which only
adds a layer of complication. Needlessly. I prefer the reverse model
- the original author cites as he sees fit - other author/editors
request additional citations on the /talk page. (Not with the silly
tag currently in use on the Wikipedia.)
Encouraging editors to cite articles properly will be vital to a new
Citizendium if it wants to avoid the problems of Wikipedia. I think what
we do need to distance ourselves from is a reluctance on the part of
editors, usually motivated by a need to place bias in articles, to avoid
citation.
The avoidance of proper support and citation at the Wikipedia is (IMO)
more a reflection of the lack of discipline inherent in its
organization than anything else. They are now over reacting in the
opposite direction, and so are we.
Post by Derek Lyons
Where did the belief arise that this
is should be done for an online compendium (or encyclopedia)?
Encyclopaedia articles do not need citation?
I never claimed they didn't - only that my impression of the citation
level being proposed for Citi seems excessive.

D.
Ricardo Gladwell
2006-09-23 09:57:45 UTC
Permalink
Post by Derek Lyons
Post by Derek Lyons
Post by Ricardo Gladwell
Citation and verifiability should be an important part of Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
It is no more possible to cite and support every passage, phrase, and
word in an article than it is to travel to the moon on the wings of
giant swans.
It is inherent in the passage quoted above.
I only suggested we colour those parts of an article that have not
been cited or verified not that every part need citation. Part of
the system could include identifying those parts of an article that
do not need citation.
I only suggested we colour those parts of an article that have not been
cited or verified not that every part need citation. Part of the system could
include identifying those parts of an article that do not need citation.
Which means, to me, that it must start colored (uncited) - which only
adds a layer of complication.
As I understand it our objective isn't to create simplicity, but a
reliable encyclopedia. The only real complication here would be a
technical one. The above could be achieved transparently for users with
the existing Wikipedia framework.
Post by Derek Lyons
Needlessly.
Citation is needless?
Post by Derek Lyons
Encouraging editors to cite articles properly will be vital to a new
Citizendium if it wants to avoid the problems of Wikipedia. I think what
we do need to distance ourselves from is a reluctance on the part of
editors, usually motivated by a need to place bias in articles, to avoid
citation.
The avoidance of proper support and citation at the Wikipedia is (IMO)
more a reflection of the lack of discipline inherent in its
organization than anything else. They are now over reacting in the
opposite direction, and so are we.
That's a purely subjective: one could quite just as easily counter-argue
that we are being blase about citation by dismissing my idea out of
hand.
Post by Derek Lyons
Post by Derek Lyons
Where did the belief arise that this
is should be done for an online compendium (or encyclopedia)?
Encyclopaedia articles do not need citation?
I never claimed they didn't - only that my impression of the citation
level being proposed for Citi seems excessive.
I thought it was "inherent" in the section quoted above?

That aside, in articles that are little more than reproductions of facts
published elsewhere it's not at all excessive to require user's cite
their sources.

Kind regards...
--
Ricardo Gladwell
Ricardo Gladwell
2006-09-22 09:47:07 UTC
Permalink
Post by Derek Lyons
Post by Ricardo Gladwell
Citation and verifiability should be an important part of Citizendium,
something lacking in a lot of Wikipedia articles. One idea would be to
colour text if that part of the article has not been properly cited and
verified, the goal being to "un-colour" the whole article so that
contributors and readers can clearly see what needs citation.
It is no more possible to cite and support every passage, phrase, and
word in an article than it is to travel to the moon on the wings of
giant swans.
I never suggested the above: I only suggested we colour those parts of
an article that have not been cited or verified not that every part need
citation. Part of the system could include identifying those parts of an
article that do not need citation.

Encouraging editors to cite articles properly will be vital to a new
Citizendium if it wants to avoid the problems of Wikipedia. I think what
we do need to distance ourselves from is a reluctance on the part of
editors, usually motivated by a need to place bias in articles, to avoid
citation.
Post by Derek Lyons
It is utter lunacy to believe this is either possible,
or desireable.
I guess that would make me mad than, but at least I'm polite and mad.
Post by Derek Lyons
When you read a popular work, this is not done.
Why are you talking about "popular" works?
Post by Derek Lyons
Where did the belief arise that this
is should be done for an online compendium (or encyclopedia)?
Encyclopaedia articles do not need citation?

Kind regards...
--
Ricardo Gladwell
http://gladwell.selfip.com/photos/
Phil Howard
2006-09-22 04:51:51 UTC
Permalink
On Wed, Sep 20, 2006 at 08:40:44PM -0700, Darren Duncan wrote:

| In particular, we could address from the start about dealing with
| homonyms, and go right from the start such that *all* normal articles
| have urls like "Foo (Bar)", and such that *all* urls with just "Foo"
| are disambiguation pages, even if there is only one meaning; there
| could be others later, so we should think ahead and design to scale,
| and that is one way to do it.
|
| If we do deal with article urls that way from the start, then all
| links can initially be "Foo (Bar)" and hence no one clicking on an
| older url is likely to come to a disambiguation page due to a "Foo"
| being split up.

I do think we need to make things more consistent than how they have
turned out in Wikipedia. And disambiguation is one such area. But I
do think it should only be done when disambiguation is actually needed.

Suppose some day in the next few years there is a rising musician who
becomes particularly popular and whose real name is Albert Einstein.
A disambiguation will be essential somewhere. But does that really
mean we need to have "Albert Einstein (physicist)" right now? Just
how well known does someone, who has the same name as someone with
great historical significance, need to be in order to create the need
to disambiguate?


| On a related note to #4, I suggest having the multiple languages
| integrated in a single database and interface, rather than having a
| separate "site" for each language.
|
| That is, users can choose a language from a menu when they enter, but
| the only distinction between what they get for doing so would be what
| language the Citizendium menus and buttons and standard components
| are in, as well as a vote for preferred language of content.
| Moreover, we only need one internet domain, and a language choice can
| be part of the path; eg: http://citizendium.org/en/whatever .
|
| Similarly, all articles in the database should be inherantly
| multi-lingual, in a fashion reminiscent to multi-lingual software,
| taking for one example how Mac OS X works. For each article (the
| "Foo (Bar)" mentioned in #4), exists one or more "language
| resources", each of which is a version of the article written in one
| language. A visitor by default sees the version in their chosen
| language, but if one doesn't exist, then can be given the option to
| either go to the version in a different language, or add a
| translation (sort of like adding a new article), or alternately see
| the external Wikipedia version in that language.

Logged in users, or non-logged in users setting preferences that get
stored by optional cookies (don't store them unless the user asks for
it) could select a list of languages. If the article does not exist
in the first choice, then the second could may be used, and so on.


| Following the principle of saying just what we actually know, I
| propose that real world names not be a strict requirement, but a soft
| requirement and/or a strong recommendation.
|
| One reason is that people can always lie, and pretend to put in a
| real name when they actually aren't. Second is that there is
| sometimes a legitimate reason for someone to hide whom they are, such
| as if what they say will get them arrested or killed by an oppresive
| regime.

An area I intend to write on is amateur radio (and in fact clean up
some mess found on WP in some of the articles). I would prefer to
have my own amateur radio callsign used. But I'm not hiding my real
name, as hams can be looked up. I should be able to be looked up
as a user in CZ in much the same way as is now in WP. This lets me
use my "commonly known name" as opposed to my real identity.

I would not be opposed to my real name showing in a hover over my
"nickname".


| All that said, this is what I propose:
|
| 1. Everyone who adds or edits anything on Citizendium must have a
| named account on Citizendium. No one can add or edit anything
| without logging in.

Agreed.


| 2. When someone creates a Citizendium account, they supply a Public
| Name, which is what someone is known by on the system, regardless of
| whether it is their real name or not (people will use their real name
| usually by recommendation), and an email address, which has to be
| verified to activate the account (admins may need to contact them) by
| sending an auto-message to it with some code, so that we know it is
| their address and they spelled it correctly. Then they provide a
| password, and separately there are various profile-type fields where
| they can put in their real name and CV and whatever.

The email addresses must be hidden from the public. Maybe we can allow
them to be exposed if the user chooses. There should be a mechanism
for any logged in user to communicate with any other user without the
email address having to be known. The addressed user should decide if
any such communications would be forwarded directly to their email
address, or if the communications will be saved on the server and a
notice that "citizendium mail is waiting" is sent if this is the first
communication since the addressed user last logged in. Additionally,
the sender should have an option to reveal their verified email address
to the user they send the communication to. Of course anyone can add
their email address to the content of their communication, but that
might not be the address they signed up to Citizendium with.

Users should be allowed to add different email addresses for different
aspects of usage (for example one address for Citizendium notifications
and another address for user-to-user email). The method to do this is
by letting the user account collect a list of verified addresses (the
process of adding them goes through verification that must pass for the
address to be successfully added), and from that list, any aspect that
needs an address can have one of them designated without the need to
verify every time. Thus each address only needs to be verified once.

Email addresses should be re-verified if a user becomes inactive for
a long period of time (to be defined).


| 3. Like a typical article, an account has its own corresponding page
| with all the profile-type details on it, and it can include its own
| cited sources that refer to the person's web site or otherwise
| external proof that they are who they say they are.
|
| 4. All Citizendium add/edit/etc activity is attached to the account,
| for crediting and by way of that to their CV or whatever.
|
| 5. Of course, someone could still lie about who they are, but what
| info they provide or how verifyable it is will contribute to the
| validity of any changes they make to the system, and what changes
| they make are tracked to the account. Generally speaking, the public
| or other systems can put more weight on one account than another, for
| determining experts et al, based on this proof attached to the
| accounts.

How should I sign up if I am wanting to use one public facing identity
for some article (e.g. my ham radio call sign for amateur radio specific
articles) and another for other articles? Should I just have 2 accounts?
Or what about 1 account that can attribute a choice name?

Presently I have multiple accounts in Wikipedia. Some of that is due to
changes in the way I approach things. My ham radio callsign is one of
them, now.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Phil Wardle
2006-09-22 05:06:31 UTC
Permalink
Agree with what you are saying regarding e-mail addresses.

But! We /really/ need to protect contributors from inadvertently
exposing themselves to spam, hate mail etc regarding their normal e-mail
accounts.

It is too easy for some people to join a forum say, provide their normal
e-mail address in good faith and then get hacked or spammed by malicious
web users.

Contributors should therefore be warned and given the opportunity of
creating a new e-mail address, say through Yahoo, or even our own
servers, so that fellow users can contact them privately (without
flooding their normal e-mail address in the case of popular or well
known individuals for instance). If that special e-mail address becomes
a target for hate mail it should be simple matter for a contributor to
delete it and create a new one.

Cheers, Phil.
Post by Phil Howard
|
The email addresses must be hidden from the public. Maybe we can allow
them to be exposed if the user chooses. There should be a mechanism
for any logged in user to communicate with any other user without the
email address having to be known. The addressed user should decide if
any such communications would be forwarded directly to their email
address, or if the communications will be saved on the server and a
notice that "citizendium mail is waiting" is sent if this is the first
communication since the addressed user last logged in. Additionally,
the sender should have an option to reveal their verified email address
to the user they send the communication to. Of course anyone can add
their email address to the content of their communication, but that
might not be the address they signed up to Citizendium with.
Users should be allowed to add different email addresses for different
aspects of usage (for example one address for Citizendium notifications
and another address for user-to-user email). The method to do this is
by letting the user account collect a list of verified addresses (the
process of adding them goes through verification that must pass for the
address to be successfully added), and from that list, any aspect that
needs an address can have one of them designated without the need to
verify every time. Thus each address only needs to be verified once.
Email addresses should be re-verified if a user becomes inactive for
a long period of time (to be defined).
-------------- next part --------------
HTML attachment scrubbed and removed
Darren Duncan
2006-09-22 06:48:28 UTC
Permalink
<snip>
I do think we need to make things more consistent than how they have
turned out in Wikipedia. And disambiguation is one such area. But I
do think it should only be done when disambiguation is actually needed.
Suppose some day in the next few years there is a rising musician who
becomes particularly popular and whose real name is Albert Einstein.
A disambiguation will be essential somewhere. But does that really
mean we need to have "Albert Einstein (physicist)" right now? Just
how well known does someone, who has the same name as someone with
great historical significance, need to be in order to create the need
to disambiguate?
Yes, do it right now. The fact that we have an article for any
person at all in Citizendium means that they have at least a modicum
of fame (at least as much as someone named in a newspaper article for
any reason). So have "Albert Einstein (physicist)" or such right now.

I'll also say for the record that a much more scalable system is one
that doesn't put any identifying details in the urls at all, or that
those aren't the actual primary key for a record in the database;
just use a non-descript number instead. Then an article can just
point to another by reference, regardless of what its name is. So if
we have two Albert Einsteins that are both physicists, we won't have
to disambiguate a link further.

The old descriptive info could be a surrogate key that can possibly
be changed now and then, but since the actual db links use the
number, that update only happens in one place, and all screens
showing the link update automatically.

Or maybe that's how Wikipedia already works, for all I know, but I
don't know. But perhaps not, because if that is how it works, we
might have article addresses changed more often because it is low
difficulty to do it properly.

That said, I suggested "Foo (Bar)" initially as it was less extreme
and could be easily accommodated into the system Wikipedia uses now,
whereas what I suggest would require more comprehensive changes.

So weigh pros and cons of either, but I present both so you can pick
a best fit.

(For the record, my own software will use the number.)
Logged in users, or non-logged in users setting preferences that get
stored by optional cookies (don't store them unless the user asks for
it) could select a list of languages. If the article does not exist
in the first choice, then the second could may be used, and so on.
Yes.

Oh, I forgot to mention this before, but for security purposes, bare
account passwords should never be stored in the database, but rather
just a 1-way hash of them, such as using SHA1 or MD5 etc. And so, if
someone forgets their password, they have to create a new one, and in
the process, their email address is re-verified. Neither staff nor
hackers will know what the password is, and no emails will be sent to
remind people of their passwords. Emails are notoriously insecure in
general, as they are unencrypted in general. I don't remember what
Wikipedia does, but some public services go one way, and others the
other way.
An area I intend to write on is amateur radio (and in fact clean up
some mess found on WP in some of the articles). I would prefer to
have my own amateur radio callsign used. But I'm not hiding my real
name, as hams can be looked up. I should be able to be looked up
as a user in CZ in much the same way as is now in WP. This lets me
use my "commonly known name" as opposed to my real identity.
I would not be opposed to my real name showing in a hover over my
"nickname".
Yes. I anticipated "pen names" or other commonly-knowns to be used
as one's public identity, and this is reasonable at times.
The email addresses must be hidden from the public. Maybe we can allow
them to be exposed if the user chooses.
I would have 2 email slots, a private one, for Citizendium admins or
automated processes to use, and an optional public one, or some such
arrangement.
There should be a mechanism
for any logged in user to communicate with any other user without the
email address having to be known. The addressed user should decide if
any such communications would be forwarded directly to their email
address, or if the communications will be saved on the server and a
notice that "citizendium mail is waiting" is sent if this is the first
communication since the addressed user last logged in. Additionally,
the sender should have an option to reveal their verified email address
to the user they send the communication to. Of course anyone can add
their email address to the content of their communication, but that
might not be the address they signed up to Citizendium with.
Absolutely. I had but didn't write such thoughts. In fact,
communication could be done without involving the email at all, more
or less.
Users should be allowed to add different email addresses for different
aspects of usage (for example one address for Citizendium notifications
and another address for user-to-user email). The method to do this is
by letting the user account collect a list of verified addresses (the
process of adding them goes through verification that must pass for the
address to be successfully added), and from that list, any aspect that
needs an address can have one of them designated without the need to
verify every time. Thus each address only needs to be verified once.
Email addresses should be re-verified if a user becomes inactive for
a long period of time (to be defined).
Absolutely.
How should I sign up if I am wanting to use one public facing identity
for some article (e.g. my ham radio call sign for amateur radio specific
articles) and another for other articles? Should I just have 2 accounts?
Or what about 1 account that can attribute a choice name?
Presently I have multiple accounts in Wikipedia. Some of that is due to
changes in the way I approach things. My ham radio callsign is one of
them, now.
First of all, each actual person should have only one Citizendium
account, and it is against the rules to have multiples.

That said, we could make it possible for one actual account to have
associated with it several mutually exclusive "pen names" or such.

So with your one account, you can work on articles in different
topics and have each section visibly signed with a different alias.

As to whether only admins know that these pen names are all the same
actual person, or whether the public does, if they bother to look, is
still a matter I haven't made up an opinion on yet. I'm inclined
public should know by default.
Agree with what you are saying regarding e-mail addresses.
But! We really need to protect contributors from inadvertently
exposing themselves to spam, hate mail etc regarding their normal
e-mail accounts.
It is too easy for some people to join a forum say, provide their
normal e-mail address in good faith and then get hacked or spammed
by malicious web users.
Contributors should therefore be warned and given the opportunity
of creating a new e-mail address, say through Yahoo, or even our own
servers, so that fellow users can contact them privately (without
flooding their normal e-mail address in the case of popular or well
known individuals for instance). If that special e-mail address
becomes a target for hate mail it should be simple matter for a
contributor to delete it and create a new one.
If we keep all messages within the database and only optionally send
them to email addresses, then the general spam problem is avoided.
Or if messages are sent without the sender knowing the address.

See the Ebay "contact this seller" system for a good example.

Also, only people with accounts can send messages to other people
through this system, so any messages sent will come from someone with
a verified known email, rather than sending a message from someone
else's address or a non-address.

-- Darren Duncan
Darren Duncan
2006-09-22 06:53:32 UTC
Permalink
Post by Darren Duncan
I'll also say for the record that a much more scalable system is one
that doesn't put any identifying details in the urls at all, or that
those aren't the actual primary key for a record in the database;
just use a non-descript number instead. Then an article can just
point to another by reference, regardless of what its name is. So
if we have two Albert Einsteins that are both physicists, we won't
have to disambiguate a link further.
The old descriptive info could be a surrogate key that can possibly
be changed now and then, but since the actual db links use the
number, that update only happens in one place, and all screens
showing the link update automatically.
Furthermore, as an existing example of what I'm talking about, look
at the IMDB (Internet Movie Database); it uses non-descript numbers
for urls, and rather than a hand-coded disambiguation page for search
results, it shows a generated page showing articles that are simliar
to the search term. We can do likewise and it should work well.

Also, the issue of what article editors put in their hyperlinks
(usually descriptive) is an orthogonal issue, and could point to a
surrogate key (from their point of view; the actual non-descript key
is saved in the database, abstracted away).

-- Darren Duncan
Phil Howard
2006-09-22 09:53:24 UTC
Permalink
On Thu, Sep 21, 2006 at 11:53:32PM -0700, Darren Duncan wrote:

| Furthermore, as an existing example of what I'm talking about, look
| at the IMDB (Internet Movie Database); it uses non-descript numbers
| for urls, and rather than a hand-coded disambiguation page for search
| results, it shows a generated page showing articles that are simliar
| to the search term. We can do likewise and it should work well.

That would be a number that references a specific topic, of which there
would be a current article. But a reference to a specific historical
occurrence of an article would need more. I think Wikipedia used times.
That could be fine to append that, though we do need to addess the year
2038 issue if we use Unix time() values in 32 bit. Use 64 bit maybe.

Another way to forever reference an exact version of an article is to
use the SHA1 hash of it as the URI.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Phil Howard
2006-09-22 09:47:24 UTC
Permalink
On Thu, Sep 21, 2006 at 11:48:28PM -0700, Darren Duncan wrote:

| I'll also say for the record that a much more scalable system is one
| that doesn't put any identifying details in the urls at all, or that
| those aren't the actual primary key for a record in the database;
| just use a non-descript number instead. Then an article can just
| point to another by reference, regardless of what its name is. So if
| we have two Albert Einsteins that are both physicists, we won't have
| to disambiguate a link further.

I was almost going to suggest the numeric approach. Of course there
will be some article topics, or at least a reference to them, that
will be numbers. So a formal "permalink" to an article's current
state, and maybe even levels of its history, could be in a different
URL branch

http://en.citizendium.org/wiki/Albert_Einstein_(physicist)
http://en.citizendium.org/akey/123456

Either could be used, though the latter may also include a list of
all the references.

Would we do that for aliases, exonyms, endonyms, or other names people
know something by? We would surely not want to redirect to the numbered
article link (but a "permalink" could be available in case someone does
want to have a very safe reference). Consider a country with two or
more names:

http://en.citizendium.org/wiki/Germany
http://en.citizendium.org/wiki/Deutschland

or

http://en.citizendium.org/wiki/Algeria
http://en.citizendium.org/wiki/Dzayer

For the English Citizendium the English exonym would normally be
expected, and should be the principle name. But do we need to have
redirects work the same way as in Wikipedia? I actually think the
way Wikipedia does it is half broken. It changes the title, but
not the URL (e.g. it doesn't do an HTTP redirect).

Maybe it's just a funny habit, but on Wikipedia I always click on
the "article" link at the time so I "finish" the redirect so I can
save or reference the "official" URL for the article. I do find a
lot of references from article go to a redirected page and the
"half broken" redirect makes things work funny.

If another article, say about relativity, makes a references to
Albert_Einstein_(physisict) and we later find a 2nd one and have
to disambiguate, do we have to go clean up all the references to
the original name, or can those be translated at save time to the
permanent number, that by default extracts the current title of
the article? I suspect this might require Mediawiki programming
to do.

|
| The old descriptive info could be a surrogate key that can possibly
| be changed now and then, but since the actual db links use the
| number, that update only happens in one place, and all screens
| showing the link update automatically.
|
| Or maybe that's how Wikipedia already works, for all I know, but I
| don't know. But perhaps not, because if that is how it works, we
| might have article addresses changed more often because it is low
| difficulty to do it properly.

There are official names, and redirect names. The redirect names
don't actually take you to the official name, but just pull of the
content from it, with the notation that it is a redirect from ...
and gives the URL you're already visiting (seems useless to me).


| That said, I suggested "Foo (Bar)" initially as it was less extreme
| and could be easily accommodated into the system Wikipedia uses now,
| whereas what I suggest would require more comprehensive changes.

I tend to dislike typing "(" or ")".

But maybe the answer is to provide better placed search mechanism so
I can just type in "Albert Einstein" and get appropriate search results
that, at least for now, would go directly to Al's page. Where there is
ambiguity, then present a dynamic disambiguation page based on what has
been found in the search (e.g. "Albert" might bring up many pages, but
I doubt we specifically want to create a page called "Albert").

There should be a URL that specifically handles the search using either
query string data or file info data from the URL so people can have
"research citizendium" boxes on other web sites. For Wikipedia, I
have to use Google, and what I get back from Google is fine for a big
search engine, but not exactly what I'd like to see for either Wikipedia
or Citizendium.


| So weigh pros and cons of either, but I present both so you can pick
| a best fit.

Let's see what others say.


| (For the record, my own software will use the number.)

OK.


| Oh, I forgot to mention this before, but for security purposes, bare
| account passwords should never be stored in the database, but rather
| just a 1-way hash of them, such as using SHA1 or MD5 etc. And so, if

Make it a salted hash with at least a 32 bit salt, to prevent pre-hashed
dictionary attacks offline if someone does get hold of the data. The
salt would be attached to the stored hash to rerun the check.


| someone forgets their password, they have to create a new one, and in
| the process, their email address is re-verified. Neither staff nor
| hackers will know what the password is, and no emails will be sent to

Agreed. But, be careful about regenerating a password. That is open to
abuse, too. I can "try" to login as you, claim my password is forgotten,
click on the button to regenerate a new one, and deny you access until
you read your email. If I were really nasty, I'd flood your mailbox to
put you over quota first, so the new password wouldn't be delivered.

When regenerating a password, the OLD password needs to keep working for
a while. So that means you need to store at least 2 password hashes in
the DB, maybe more. To get the old password deleted immediately, enter
the old password. If you really forgot it, hopefully no one else had it.

There also needs to be a limit on the number of password regenerates a
day, but not less than 2.

Hopefully you won't forget your email access password.


| remind people of their passwords. Emails are notoriously insecure in
| general, as they are unencrypted in general. I don't remember what
| Wikipedia does, but some public services go one way, and others the
| other way.

The worst security, IMHO, is the passwords sitting on the mail server.
Recently I was collaborating with someone that involved us creating
password a few times and sending to the other. He was at first using
his DSL provider emailbox. Later he switched to Gmail. I was not so
comfortable with the passwords sitting there. But when he sent me a
password, I was less concerned because those coming to me sat on my
own mail server (though the ones he sent from Gmail might still also
be there as well).

One way to deal with this is require that generated passwords be changed
very soon, and each login with them reminds them to make the password
change real soon. But, it should not absolutely force them to do so
immediately. I find that making people think up a password too quickly
ends up with yet another forgotten password. I'd say let a generated
password work for 72 hours after first logged in with, or 168 hours
after generated, whichever is first.


| Yes. I anticipated "pen names" or other commonly-knowns to be used
| as one's public identity, and this is reasonable at times.

It should definitely be tied to the real name.

OTOH, I still might put up a ham radio wiki. At least then words can
be specific to ham radio where in Citizendium or Wikipedia they would
be very ambiguous, if not outright trivial.


| First of all, each actual person should have only one Citizendium
| account, and it is against the rules to have multiples.
|
| That said, we could make it possible for one actual account to have
| associated with it several mutually exclusive "pen names" or such.
|
| So with your one account, you can work on articles in different
| topics and have each section visibly signed with a different alias.
|
| As to whether only admins know that these pen names are all the same
| actual person, or whether the public does, if they bother to look, is
| still a matter I haven't made up an opinion on yet. I'm inclined
| public should know by default.

The public should be able to get the real world name from the pen name
without any doubt. I would like to restrict displaying a list of all
the pen names to only those who log in. Still, an anonymous user who
wonders if it is the same person behind 2 different pen names, can find
out.

Larry indicated he might be opposed to this, but it was not clear if
he wanted the pages to be literally signed by real world name, or if
it would be good enough that real world names can be accessed via the
pen name.

Perhaps certain categories, such as "amateur radio" can allow specific
pen names if they are not otherwise allowed for most articles.


| If we keep all messages within the database and only optionally send
| them to email addresses, then the general spam problem is avoided.
| Or if messages are sent without the sender knowing the address.
|
| See the Ebay "contact this seller" system for a good example.
|
| Also, only people with accounts can send messages to other people
| through this system, so any messages sent will come from someone with
| a verified known email, rather than sending a message from someone
| else's address or a non-address.

One problem that many mailing lists have encountered is that people at some
large ISPs such as AOL are frequently marking email as spam, result in the
spam count for the outgoing mail server to go up, and eventually being
blocked. So maybe we don't want to actually ever send any content that is
posted from a web page. Maybe send a notice that new content has arrived.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Darren Duncan
2006-09-22 11:10:31 UTC
Permalink
Post by Phil Howard
| someone forgets their password, they have to create a new one, and in
| the process, their email address is re-verified. Neither staff nor
| hackers will know what the password is, and no emails will be sent to
Agreed. But, be careful about regenerating a password. That is open to
abuse, too. I can "try" to login as you, claim my password is forgotten,
click on the button to regenerate a new one, and deny you access until
you read your email. If I were really nasty, I'd flood your mailbox to
put you over quota first, so the new password wouldn't be delivered.
When regenerating a password, the OLD password needs to keep working for
a while. So that means you need to store at least 2 password hashes in
the DB, maybe more. To get the old password deleted immediately, enter
the old password. If you really forgot it, hopefully no one else had it.
In the system I propose, an extra database table, say email_test,
would be used during either account creation or password replacement;
it contains the email address being tested and a copy of the code
sent to that address; a record is added when the user tries to create
an account or get a password reminder, and it is deleted either when
they enter the right code, or there is a time-out (I suggest 6
hours); if they hit "remind" several times, then the generated emails
all contain the *same* code.

No changes are made to the actual user accounts table, and if the
original user doesn't act on the reminder emails, they eventually
time out and nothing happens. The user can still log in with their
old password until they explicitly change it using the emailed code.

Note that I have working implementation code for this account
creation method, in production use, which I could share (proprietary
details obfuscated) if it would be useful.

This is what the auto-email produced by said code says:

Date: Fri, 22 Sep 2006 04:04:42 -0700
From: submitter-agent at hotelsmotels.com
To: darren at darrenduncan.net
Subject: HotelsMotels.com - Account Email Confirmation

--------------------------------------------------
This e-mail was sent at '2006-09-22 11:03:25 UTC'
by the web site 'FooBar.com' (http://foobar.com).
It is the result of a web form submission from an anonymous public site
visitor at '24.69.53.198';
the submitted form was located at 'https://foobar.com/submit.extenshun'.
If that visitor was not you, then you can safely ignore this message.
--------------------------------------------------

The confirmation code for email 'darren at darrenduncan.net' is
'88766465351474593927'

--------------------------------------------------
END OF MESSAGE
Post by Phil Howard
There also needs to be a limit on the number of password regenerates a
day, but not less than 2.
Sure. My code doesn't do that, but it could be added.
Post by Phil Howard
Hopefully you won't forget your email access password.
Not if my idea is followed. The original user is safe if they
remember their Citizendium password, as no one else can change it on
them without access to their email address. But if they do forget
both, well that's a problem I have yet to work out a good solution to.
Post by Phil Howard
One problem that many mailing lists have encountered is that people at some
large ISPs such as AOL are frequently marking email as spam, result in the
spam count for the outgoing mail server to go up, and eventually being
blocked. So maybe we don't want to actually ever send any content that is
posted from a web page. Maybe send a notice that new content has arrived.
The method I propose does not send anything to the email address that
isn't defined or generated by us; no user content will be in it. The
worst that can happen is that a victim gets a load of identical
messages from us. See the above email example.

-- Darren Duncan
Darren Duncan
2006-09-22 11:18:49 UTC
Permalink
<snip>

Er, since I accidentally neglected to obfuscate part of that
generated email example, I suppose you now know one place where you
can see the live version.

However, please don't act on that knowledge.

Thank you. -- Darren Duncan
David Gerard
2006-09-21 09:35:20 UTC
Permalink
[accidentally sent only to Kim first time]
Post by Kim van der Linde
Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
our standards in the first six months. That effectively means that when
people come to citizendium, they have a change of one in 120 to hit an
improved page, for the rest, it is just old unreliable Wikipedia that
they will see. Aka, we will be perceived equally bad as them. For that
reason, I suggest we modify the 'article not found' page by including an
explicit link to Wikipedia, with an appropriate message. In that way, we
make explicit what is us and what is them. It is also an incentive for
citizendium editors to get as soon as possible as many as possible pages
updated and to par with our quality standards.
A possible start on getting quality articles: a not-yet-started
project I'm pushing on Wikipedia:

http://en.wikipedia.org/wiki/Wikipedia:100%2C000_feature-quality_articles

or, [[WP:100K]]. Featured Articles is the most exacting quality filter
on Wikipedia, but there are many others which may be places to look
for articles requiring not too much work to get up to scratch.

Another idea: featured articles from other-language Wikipedias. German
Wikipedia for example is reputedly much higher quality than English
Wikipedia, and has released three stable editions on DVD/CD. (i.e.,
the wiki model has actually produced an encyclopedia product that
people will pay real money for.) A good translation would require
someone with subject knowledge who speaks both languages well ...


- d.



- d.
Peter Hitchmough
2006-09-21 19:08:02 UTC
Permalink
I still prefer the cleanest possible presentation of a page's main
view, with no "colour sections" or overt differentiation of sources.

A suggestion - some other view of the page could be possible. In
addition to a Wikipedia-style history page, there can be a view (page)
showing the data sources.

I could be persuaded if the entire page were coded by background
colour: pristine black on white for competently edited, a range of
pastels for other qualities.

- Peter
Phil Wardle
2006-09-21 23:10:42 UTC
Permalink
Modern software and the hardware it runs on is more than capable of
allowing a user to tailor his/her interface to whatever "theme" they like.

A "Citi" project should be no less sophisticated.

One of the things I truly hate about Wikipedia is the primitive options
available for searching, interface selection (none) and editing...it's
worse that DOS in many ways. Citi's software should be */much/* better,
I would hope (depending on available OSS of course).

Phil.
Post by Peter Hitchmough
I still prefer the cleanest possible presentation of a page's main
view, with no "colour sections" or overt differentiation of sources.
A suggestion - some other view of the page could be possible. In
addition to a Wikipedia-style history page, there can be a view (page)
showing the data sources.
I could be persuaded if the entire page were coded by background
colour: pristine black on white for competently edited, a range of
pastels for other qualities.
- Peter
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
-------------- next part --------------
HTML attachment scrubbed and removed
Jesse W
2006-09-22 00:52:49 UTC
Permalink
Excuse me?
Modern software and the? hardware it runs on is more than capable of
allowing a user to tailor his/her interface to whatever "theme" they like.
A "Citi" project should be no less sophisticated.
One of the things I truly hate about Wikipedia is the primitive
options available for searching,
You got us there. Mainly due to hardware issues. There are a number
of imaginitve tricks with external search engines, but they arn't
(AFAIK) documented very well.
interface selection (none)
I presume from this you haven't looked at the "skins" section of the
preferences page (with 5 other skins available), or looked into
Monobook.css (or even Myskin.css if you want to make it all yourself)
modifications , or seen the Gallery of User Created Skins (I think it's
called) or the WikiProject User scripts (which has a large number of
add-on javascripts that do a large variety of interesting things), etc,
etc. MediaWiki has interface selection up the wazoo; if you haven't
found it, it must be because it's not explained well enough in the
places you've been looking. (URLs provided on request)
and editing...it's worse that DOS in many ways.
Details, please. IIRC, DOS was line-oriented, and, more importantly, a
shell; the edit box on MediaWiki isn't either of those. (last I
checked).

Jesse Weinstein
Zachary Pruckowski
2006-09-22 01:15:24 UTC
Permalink
I'm guessing you're a MediaWiki programmer or at least semi-
knowledgeable with the code?

I too think searching needs some work. Even if we redirect searches
to a Google search of our site (site:citizendium.org parameter),
that'll help. I mean, I recognize the complexity of doing a search
in that complex of a database.

I think he's also looking at the lack of a toolbar that compares to
some Word Press ones I've seen (and maybe he has his settings
wrong). For instance, a "select the text and push a button to make
it bold/italic/whatever" set of buttons, along with easier picture
inserter or something is probably what he meant. I don't really
notice it, since I don't use it in Wikipedia, but a lot of vB forums
or WordPress blogs have nice setups like that.

And yes, please set up the list with any sort of MediaWiki tutorial
link you've got. Put it on the Textop wiki somewhere if possible.

Zachary Pruckowski
UVA CLAS 2009
Post by Jesse W
Excuse me?
Post by Phil Wardle
Modern software and the hardware it runs on is more than capable of
allowing a user to tailor his/her interface to whatever "theme" they like.
A "Citi" project should be no less sophisticated.
One of the things I truly hate about Wikipedia is the primitive
options available for searching,
You got us there. Mainly due to hardware issues. There are a number
of imaginitve tricks with external search engines, but they arn't
(AFAIK) documented very well.
Post by Phil Wardle
interface selection (none)
I presume from this you haven't looked at the "skins" section of the
preferences page (with 5 other skins available), or looked into
Monobook.css (or even Myskin.css if you want to make it all yourself)
modifications , or seen the Gallery of User Created Skins (I think it's
called) or the WikiProject User scripts (which has a large number of
add-on javascripts that do a large variety of interesting things), etc,
etc. MediaWiki has interface selection up the wazoo; if you haven't
found it, it must be because it's not explained well enough in the
places you've been looking. (URLs provided on request)
Post by Phil Wardle
and editing...it's worse that DOS in many ways.
Details, please. IIRC, DOS was line-oriented, and, more
importantly, a
shell; the edit box on MediaWiki isn't either of those. (last I
checked).
Jesse Weinstein
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
Jesse W
2006-09-22 01:25:39 UTC
Permalink
Post by Zachary Pruckowski
I'm guessing you're a MediaWiki programmer or at least
semi-knowledgeable with the code?
Not really; I'm a programmer, but not really of MediaWiki.
Post by Zachary Pruckowski
I too think searching needs some work. Even if we redirect searches
to a Google search of our site (site:citizendium.org parameter),
that'll help. I mean, I recognize the complexity of doing a search in
that complex of a database.
I know, I know; I really need to write up the few external search
tricks I know. There arn't that many: site: , inurl:wiki/NAMESPACE ,
or inurl:wiki/PAGE/ for subpages. I think that's about it. But it
does help.
Post by Zachary Pruckowski
I think he's also looking at the lack of a toolbar that compares to
some Word Press ones I've seen (and maybe he has his settings wrong).
Yes, MediaWiki does have such a toolbar. (I don't use it either).
Post by Zachary Pruckowski
And yes, please set up the list with any sort of MediaWiki tutorial
link you've got.
Well, all this stuff should be accessable from http://mediawiki.org
(although I'm not sure if it is)

Jesse Weinstein
Phil Wardle
2006-09-22 01:22:12 UTC
Permalink
Well you got me back!

Got to laugh though.

You are quite right, I haven't found the "Skins" section of Wiki,
because I'm usually too busy correcting the typos and/or poor grammar on
the day's featured articles (an exaggeration of course, but it sometimes
seems that way). Indeed there is much about the structure and options of
Wiki that I haven't been bothered to chase down, because I'm more
interested in reading the damn thing! Whatever it's faults, it can suck
you in for hours by just following the hyperlinks.

What I should have said is that the editing screen for Wiki, although
more than adequate, is not as easy or intuitive to use as say the better
GUI Webpage software available today. Forcing new and perhaps
technologically fearful contributors to learn even the basic syntax of
the Wiki editing procedure seems to me to be old hat. Of course, being
relatively new to Wikipedia and hence still on the learning curve of all
that it is capable of, my views and comments may not count for much
regarding these features.

Whatever, I know that when I create a website for someone these days,
the software I use makes the whole thing a great deal easier than a
similar attempt at creating an article on Wikipedia.

Just my 2c and not worth taking up bandwidth at this juncture. We have
more important things to get right first.

P.S. Any retorts that include the words "thick", "stoopid" etc., will
result in an automatic ban ....(joke ;-)

Cheers, Phil.
Post by Jesse W
Excuse me?
Post by Phil Wardle
Modern software and the hardware it runs on is more than capable of
allowing a user to tailor his/her interface to whatever "theme" they like.
A "Citi" project should be no less sophisticated.
One of the things I truly hate about Wikipedia is the primitive
options available for searching,
You got us there. Mainly due to hardware issues. There are a number
of imaginitve tricks with external search engines, but they arn't
(AFAIK) documented very well.
Post by Phil Wardle
interface selection (none)
I presume from this you haven't looked at the "skins" section of the
preferences page (with 5 other skins available), or looked into
Monobook.css (or even Myskin.css if you want to make it all yourself)
modifications , or seen the Gallery of User Created Skins (I think it's
called) or the WikiProject User scripts (which has a large number of
add-on javascripts that do a large variety of interesting things), etc,
etc. MediaWiki has interface selection up the wazoo; if you haven't
found it, it must be because it's not explained well enough in the
places you've been looking. (URLs provided on request)
Post by Phil Wardle
and editing...it's worse that DOS in many ways.
Details, please. IIRC, DOS was line-oriented, and, more importantly, a
shell; the edit box on MediaWiki isn't either of those. (last I
checked).
Jesse Weinstein
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
-------------- next part --------------
HTML attachment scrubbed and removed
Peter Hitchmough
2006-09-22 12:08:14 UTC
Permalink
---------- Forwarded message ----------
From: Peter Hitchmough <peterh.uk at gmail.com>
Date: Sep 22, 2006 12:59 PM
Subject: Re: [Citizendium-l] reliability, homonyms, content, sources,
editors, multinationals
To: Phil Wardle <phil_wardle at iprimus.com.au>


Hi Phil,

I agree. I'm thinking more of a Model View Controller design for the
Citi project so that the data IS the model, and 1) users can choose
themes and 2) beyond that, the system can present different views for
different purposes.

Cheers,
Peter
Post by Phil Wardle
Modern software and the hardware it runs on is more than capable of
allowing a user to tailor his/her interface to whatever "theme" they like.
A "Citi" project should be no less sophisticated.
One of the things I truly hate about Wikipedia is the primitive options
available for searching, interface selection (none) and editing...it's worse
that DOS in many ways. Citi's software should be much better, I would hope
(depending on available OSS of course).
Phil.
I still prefer the cleanest possible presentation of a page's main
view, with no "colour sections" or overt differentiation of sources.
A suggestion - some other view of the page could be possible. In
addition to a Wikipedia-style history page, there can be a view (page)
showing the data sources.
I could be persuaded if the entire page were coded by background
colour: pristine black on white for competently edited, a range of
pastels for other qualities.
- Peter
_______________________________________________
Citizendium-l mailing list
Citizendium-l at lists.purdue.edu
https://lists.purdue.edu/mailman/listinfo/citizendium-l
--
-------------
Peter (Dizzley)
- Some mornings it just doesn't seem
worth chewing through the leather straps.
(Emo Phillips)
--
-------------
Peter (Dizzley)
- Some mornings it just doesn't seem
worth chewing through the leather straps.
(Emo Phillips)
David Gerard
2006-09-21 20:02:15 UTC
Permalink
Post by David Gerard
or, [[WP:100K]]. Featured Articles is the most exacting quality filter
on Wikipedia, but there are many others which may be places to look
for articles requiring not too much work to get up to scratch.
Featured Articles isn't a filter - it's a skimmer. It removes
existing cruft and detritus from the article, but does nothing to
prevent it from returning.
Sure it does. The Featured version is still right there in the
history. The current version may suck, but the Featured version is
still entirely available, GFDLed, etc.


- d.
Phil Howard
2006-09-22 04:10:21 UTC
Permalink
On Mon, Sep 18, 2006 at 09:42:53AM -0400, Kim van der Linde wrote:

| 1. anonymous editing. This is only a problem at Wikipedia because it
| facilitates vandalism and insertion of nonsense, but some anonymous
| editors are adding real good content. The problem comes with the fact
| that what they add is immediately visible for the world, and as such,
| becomes a magnate for vandalism. If we get a level of editorial control
| (approve flagging), the vandalism will never reach the published pages.
| As such, we are trying to do a double kill on vandalism etc.
|
| 2. Real world names. Nice, but unnecessary. For the editors I can see
| this requirement, but along the same line as for anonymous editing,
| double kill of a problem, and potentially chasing people away.

I do think that anonymous editing should be avoided, but those who do
prefer to remain anonymous should still be able to contibute something
like a suggestion or comment, that could then be rolled into the full
article by an editor or perhaps even an author.

I have added anonymous comment to Wikipedia, but primarily because I was
too lazy to go login. Generally these were very minor things, like a
small spelling error, or an outdated link.

I cannot say why everyone who contribute anonymously does so that way.
If they have a reason to remove their identity from the public then I
think we should accomodate that in some way. They'd still login, but
their real identity would hidden. People can, and probably do, use
completely false identities just to remain anonymous. The practice
exists extensively on web pages like guest books of many sites just for
things like spam avoidance. And I'm sure sites like MySpace are just
full of false identities. I know it is a common practice for someone
in a school to put up a whole MySpace site for someone else that has
really never visited, giving the impression they have.

We might need to consider essential anonymity for contributions to a
controversial article where what they present could put them in danger
in their country or jurisdiction. We could become subject to legal
issues in trying to discover who such a person is. We normally see
this with journalists protecting their sources. Remember that what
is journalism today becomes history tomorrow, and what was journalism
yesterday, is history today. And even today's journalism frequently
digs up information from the past that wasn't known before.

The compromise I think is viable is to accept anoymous contributions,
but just queue them for editor approval. There might also be a way to
access what the not-yet-approved-or-rejected contributions are from a
link added in the article.

And finally on this, I do believe it is OK to use a public facing name
that is different than one's real name. We should strive to have such
sources fully identifiable somewhere, eventually, with the exception of
editor sponsored anonymity for the special cases.


| 3. Progressive fork. In my opinion, probably the worst idea possible.
| Wikipedia has 1.2 million pages. Suppose we can update 10.000 of them to
| our standards in the first six months. That effectively means that when
| people come to citizendium, they have a change of one in 120 to hit an
| improved page, for the rest, it is just old unreliable Wikipedia that
| they will see. Aka, we will be perceived equally bad as them. For that
| reason, I suggest we modify the 'article not found' page by including an
| explicit link to Wikipedia, with an appropriate message. In that way, we
| make explicit what is us and what is them. It is also an incentive for
| citizendium editors to get as soon as possible as many as possible pages
| updated and to par with our quality standards.
|
| As an added motivation, if citizendium gets soon the benefit of the
| doubt with the main public, we effectively become the content provider
| for Wikipedia, with the costs of additional infrastructure (wikipedia
| runs 100+ servers?) for what is effectively not our work, with content
| that could be seriously substandard.

I would agree with this. Just add a link for an editor to approve the
transfer of the article. Nothing should be in Citizendium without at
least someone having a look at it, and either cleaning it up, or at the
very least specifying what work it needs.

There may be articles that are important to transfer even before someone
can clean them up. One editor or author may feel it is important to have
now but do not feel they are sufficiently expert to do so. Maybe a queue
listing such articles can get them more rapidly addressed.

And of course, copying articles in part can be done. Just copy and edit
it down, and the original is still in the history.


| 4. Copyeditors. Copyeditors are of paramount importance. Many academics
| are good in writing academic texts, which is different from writing for
| the general public. As such, we will need talented copy editors who like
| to improve the general reading quality of articles, or just to flag
| where things are difficult to follow. Good copyeditors should IMHO get
| the freedom to copyedit pages within specific fields that they
| understand, without having to run them along the editors all the time
| (more like a afterwards check).

I like that idea.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
David Gerard
2006-09-22 09:32:02 UTC
Permalink
Post by Phil Howard
I do think that anonymous editing should be avoided, but those who do
prefer to remain anonymous should still be able to contibute something
like a suggestion or comment, that could then be rolled into the full
article by an editor or perhaps even an author.
I have added anonymous comment to Wikipedia, but primarily because I was
too lazy to go login. Generally these were very minor things, like a
small spelling error, or an outdated link.
I cannot say why everyone who contribute anonymously does so that way.
Most of it I think is because creating yet *another* web login is a
pain in the backside.
Post by Phil Howard
We might need to consider essential anonymity for contributions to a
controversial article where what they present could put them in danger
in their country or jurisdiction.
Nutters and stalkers come to Wikipedia whenever it's covering
controversial issues. This is not a function of Wikipedia but of the
Internet and of talking about controversial issues. Who's going to try
to write a neutral view-from-20,000-feet article on Israel-Palestine
and not fear harassment? Who's going to write about the Church of
Scientology and not fear harassment per written CoS policy?
Post by Phil Howard
The compromise I think is viable is to accept anoymous contributions,
but just queue them for editor approval. There might also be a way to
access what the not-yet-approved-or-rejected contributions are from a
link added in the article.
On this issue, it's important not to overwork the reviewing experts. I
think this has been noted before, but the less that requires an expert
overview the better.


- d.
Loading...