David Goodman gives a very fair and accurate summary of our interactions in
the AmSci Forum (though I would not have said that some were unfriendly --
just impatient, on my part; and if anything, I'm even more impatient now
that another half-decade has gone by and we still don't have universal OA!).
Regarding the Wikipedia entry for OA, I would add only that the proof is in
the outcome: Yes, I had no choice but to let things take their natural
course with the "Open Access" entry, as David and Peter urged. And yes, it
did become "Open Access (publishing)." But, the result is that now the
widespread misconception that "Open Access" means "Open Access Publishing"
-- it does not -- is all the more widespread and entrenched, thanks to that
natural "echo-amplification" outcome in Wikipedia.
If someone considers that to be some sort of a triumph or vindication on
behalf of something or other, I have no idea what that something is!
Wikipedia has simply served as a megaphone for amplifying misinformation in
this case.
So much for conflating OA with OA publishing.
I would say it's not at all accurate to say that I oppose OA publishing
("Gold OA"): I don't. (In fact I am pretty sure it will eventually prevail,
and have been saying so since the very beginning.) I simply assign it a
different priority, in time, importance, urgency, causality and potential,
relative to OA self-archiving ("Green OA") at this time, for very specific,
concrete, practical, evidence-based reasons (which I will not rehearse
here).
I also don't, didn't, and never aspired to "own" the OA entry in Wikipedia.
It was written by many people long before I knew about it, and before I
contributed portions to a few of its subsections (the ones on Green OA and
Institutional Repositories). I occasionally look at those sections still,
but I largely stopped trying to fix them any more when my edits were
repeatedly over-ruled on several points in which I felt that the Wikipedia
outcome was just plain wrong.
But nothing about OA is rocket science, and the only thing hanging in the
balance is more lost time... The outcome itself is obvious, optimal and
inevitable -- just long overdue.
Yours impatiently,
Stevan Harnad
http://openaccess.eprints.org/http://amsci-forum.amsci.org/archives/American-Scientist-Open-Access-Forum.…
On Sat May 15 23:06:14 David Goodman wrote:
Some background:
> When I was a librarian open access was one of the principal things I
worked on. Stevan has been for over 10 years an acknowledged leader
in this field, and his propaganda for open access has been a key
factor for the considerable success it has had--by now all major US
and UK granting agencies require it or are about to do so. All of
us who use academic material are very much indebted to him, for I do
not think it would have happened to anywhere near this extent without
him.
> But Stevan is very much set on his own preferred way of doing this.
His way is good, but he thinks that only his way is good--to the
extent that he has often tried to argue against other ways, even
though they differ only in detail, and most of his activism in the last
few years has been against other open access advocates. (I am, as you
gather, one of the people who thinks other ways are at least as good
or possibly better, and I have had many public & private discussions
about this with him over the years, not all of them friendly. ).
> There are two basic methods:
> One is known as "Gold" open access, publishing by open access
publishers in journals that are free to the reader, the costs being
paid through some form of direct or indirect subsidy from the author,
his institution, his granting agency, or other financing arrangement.
(Familar examples of this are PLOS or BMC).
> The other is known as "Green" open access, publishing in journals in
the conventional way, but also putting the articles, or at least
unedited drafts of the manuscript, into a repository. There are two
types: using a centralized repository , either on a nationwide or
subject-wide basis (the familiar examples of which are PubMed Central
in biomedicine and arXiv in physics), or alternatively on an
institution-wide basis (good examples are Harvard's DASH or Stevan's
own repository at Southampton, ECS )
> The only form Stevan supports is institutional repositories. (For
reasons, I refer you to his many long postings on American Scientist
Open Access Forum , which he moderates in accord with his own views.)
He opposes the term open access publishing because it suggests "Gold"
Open Access publishers.
> When I joined WP three years ago, I found that Stevan was exercising
OWNership over the WP article on open access, which almost totally
focussed on institution-based repositories and referenced a great
number of his own writings. When I and other made changes, Stevan
always reverted them.
> Stevan attempted to get his form of the article fixed by personal
intervention with an eminent open access supporter very close to his
own views who was a member of the WMF Advisory Board, and I believe
also with Jimbo. I am also a professional acquaintance of that
supporter, an extraordinarily fair-minded person trusted by everyone
dealing with the subject at all, and between us in personal discussion
with Stevan we were able to convince Stevan to let community processes
deal with the article.
> As phoebe says, the current wording is reasonable.
> David Goodman, Ph.D, M.L.S.
http://en.wikipedia.org/wiki/User_talk:DGG
Stillwater Rising writes:
Hosting these images without 18 USC 2257(A) records, in my opinion, is a *
> no-win* situation for everyone involved.
>
This raises the obvious question of how you interpret 18 USC 2257A(g),
which refers back to 18 USC 2257(h) (including in particular 18 USC
2257(h)(2)(B)). I'll be interested in hearing your thoughts about the
interaction and interpretation of these related statutes (as well as of the
interaction between 18 USC 2257(h) generally and 47 USC 230 and 231,
referenced within section 2257.
--Mike
Here here. There is a tactical map of 18th century Boston by Lt. Page of the
British Army on commons that I really am just blown away by. I believe it is
a featured picture, if anyone is interested. Also I saw a brilliant photo of
a homeless person in Philidelphia that could have been put on a magazine
cover. We are fortunate to have these things. Let's not forget this.
On May 21, 2010 5:09 PM, "AGK" <wikiagk(a)googlemail.com> wrote:
2010/5/21 Delphine Ménard <notafishz(a)gmail.com>:
> ...we should not forget, that there are on Commons some of the most
> beautiful images I've ever s...
Well said.
AGK
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikime...
On Fri, May 21, 2010 at 3:34 PM, FT2 <ft2.wiki(a)gmail.com> wrote:
> Might help to sum up what exactly it does or how it's used (2-4 bullet
> points) so that people trying to pick a name to match its features but
> haven't followed the lengthy debate, are up to date on it.
>
That's fair. Here's the gist of it:
* An unprotected article gets put under "Pending Revisions"/"Double Check"
by an admin
* From that point forward, edits from anonymous users are listed as
"pending revisions", and aren't displayed to other anonymous readers by
default (though they'll be accessible from a "pending revisions" tab)
* Any autoconfirmed user can then mark the latest pending revision as
"accepted", or revert to the latest accepted revision.
I just uploaded a bunch of images that may help people visualize the feature
as we see it:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_rev…
Here's the permissions as we're currently planning to deploy them for the
trial:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_rev…
Rob
Hello,
On Bugzilla I reported my observations about changes in FlaggedRevs
extension: https://bugzilla.wikimedia.org/show_bug.cgi?id=23615
I am unhappy that you attempting to enable FlaggedRevs on en.wiki, you
forget about other projects.
Regards,
Daniel aka Leinad
David Goodman writes:
I have been taking an extreme anticensorship position, but I would
> consider this acceptable. People certainly do have the right as
> individuals to select what they want to see. It is not censorship,
> just a display option Such display options could be expanded--I
> would suggest an option to initially display the lead paragraph only,
> of articles in certain categories.
>
I just had a thought -- what if it were possible for a user to categorically
block views of any images that are not linked to in any project's article
pages? Presumably, those Commons images that are found in articles are
relevant and appropriately encyclopedic (speaking generally -- I also assume
there are some exceptions). Images that were just "dumped" to Commons
without being associated with any particular article would still be
available to those who were looking for them -- perhaps to complement a
particular article that needs illustration -- but the umpteenth superfluous
porn shot (or unconnected Muhammed image) would be invisible to those who
chose this option.
Obviously, this notion is too cute to actually be helpful, but I thought I'd
share it.
--Mike
As requested, here's the weekly Flagged Protection update.
The quick summary is that we are continuing with pre-rollout activities,
including UI polish, text and naming cleanup, and rollout planning.
One important milestone passed is that Tim Starling has looked over the
code and done some profiling and given it his blessing from a
performance perspective. He and the rest of the ops folks feel like the
production gear is also in good shape for rolling this out. However, to
prevent unpleasant launch surprises we've put in a configurable limit to
the number of pages protected with this. We'll start out at a limit of
2000 and bump it up based on actual production performance.
We believe we are technically ready to try out a labs version of the
German config, just to double-check that our recent work will cause them
no headaches. However, we need some German-speaker at least hazily
familiar with FlaggedRevs to prepare the main page and help us with a
call for testers. Any assistance there would be appreciated!
Speaking of assistance, we always welcome people trying out the
extension before it goes live. You can do that here:
http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page
To see what we've changed this week, there's a list here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Flagged_Protection_upd…
To see the upcoming work, it's listed in our tracker, under Current and
Backlog:
http://www.pivotaltracker.com/projects/46157
We expect to release to labs again next week, and each week thereafter
until this goes live on the English Wikipedia.
William
I have a few questions about the deployment of Vector in Wikipedias in
other languages.
1. When does the Foundation plan to perform the switch?
2. At least two major features which were not included in the Beta,
were enabled in the English Wikipedia: the new search box with "Go"
and "Search" buttons and the collapsible sidebar which hides
interlanguage links by default. A significant number of users in
en.wikipedia expressed their dissatisfaction with them and with the
fact that they were introduced by surprise. They are still not a part
of the Beta in other languages. Will they be enabled in other
languages when they are switched to Vector?
3. Did anyone consider appointing "Vector migration czars" in
Wikipedias in other languages? Because despite what some people might
think, quite a lot of speakers of other languages don't bother looking
at en.wikipedia and WMF blogs and mailing lists. I wrote a little
about the good (IMHO) and the bad (IMHO) features about Vector in the
Village Pumps of Wikipedias in languages that i know - Hebrew, Russian
and Catalan. I can report that there are a couple of JavaScript gurus
in he.wikipedia who have a positive attitude towards Vector and who
gradually adapt the gadgets to it, and there are a few other JS gurus
who hate Vector and who don't want to bother about it and recommend
everyone to stay with Monobook. (Although my attitude may seem
negative, i actually belong to the first camp.) The situation is
similar in the Russian Wikipedia.
4. Finally, does the Foundation plan to gather any other feedback from
other language Wikipedias except the "Beta retention rate"?
Thanks in advance.
--
אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
Jehochman has suggested that we need legal advice from the Foundation at
http://commons.wikimedia.org/wiki/Commons_talk:Sexual_content
with respect to § 2257[1}, and I tend to agree with him. The relevant discussion is here:
http://commons.wikimedia.org/wiki/Commons_talk:Sexual_content#The_Case_for_…
Editors have stated that the record-keeping requirements of § 2257 do not apply to Commons. Do we have a qualified legal opinion that backs this assertion up?
From reading § 2257, it seems it is written with commercial providers of sexually explicit material in mind. Commons is not a commercial provider of such works. On the other hand, Commons licences state that material hosted on Commons is good for any use, including commercial use. This makes Commons a potential link in a chain leading to commercial use of material uploaded to Commons.
Note that per § 2257 (h)(2)(iii), anyone
"inserting on a computer site or service a digital image of, or otherwise managing the sexually explicit content of a computer site or service that contains a visual depiction of, sexually explicit conduct"
is liable to receive a prison sentence of up to 5 years, for a first-time offence, if they fail to comply with the record-keeping requirements of § 2257.
Doesn't this raise the possibility that Commons administrators might become personally liable if, for example, they decide to keep a sexually explicit image that is subsequently found to have depicted a minor?
There are other aspects involved in drafting Commons:Sexual_content that need expert legal input, for example, which types of pornography are legal in the US, and which ones are not.
We are all laypersons there, so please help us out.
Andreas
1 http://www.law.cornell.edu/uscode/718/usc_sec_18_00002257----000-.html