Greetings,
I'm very excited to welcome Ryan Kaldari to the Wikimedia Foundation as the Front End developer for fundraising. Ryan joins us from MTV Networks: Country Music Television, where he worked as a web developer responsible for several integration and architecture projects. Previous to that he helped develop Sitemason, an enterprise content management system used by numerous businesses, organizations, and colleges.
He's a long time Wikimedian who's been editing Wikipedia since 2004 and has been an admin since 2005. Some of you may have met him at the Paris Multimedia conference.
You can find what's kept him busy at http://en.wikipedia.org/wiki/User:Kaldari
He'll be starting June 1st and will work in the San Francisco office.
Ryan will bring in some much needed skills and experience to our fundraising software developments. He'll help us catch up on a lot of our pending fundraising software development projects, develop new tools and improve general infrastructure and will bring more general awesomeness to the team. He'll also work extensivelyto support and improve CiviCRM as our fundraising database platform.
Please join me in welcoming Ryan to the Wikimedia team! We'll be setting up his email as his start day gets closer but until then, you can reach him at <kaldari(a)gmail.com>.
--
Tomasz Finc
Engineering Program Manger - Fundraising, Mobile, & Offline
_______________________________________________
Please note: all replies sent to this mailing list will be immediately directed to Foundation-L, the public mailing list about the Wikimedia Foundation and its projects. For more information about Foundation-L:
https://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________
WikimediaAnnounce-l mailing list
WikimediaAnnounce-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
Earlier:
> If Mediawiki had been named Mediawiki Engine, and Wikimedia had been named
> Wikimedia Organization, part of the current confusion for outsiders would
> already have gone.
> They may not understand from the name what kind of engine, of what kind of
> organization, but they will have less trouble to tell these terms apart.
Eh I realize that example was not well chosen. I take it back ;-)
People would of course confuse Wikimedia Organization (the movement)
with Wikimedia Foundation (the organization).
Erik Zachte
On May 24, 2010, at 1:57 AM, "Erik Zachte" <erikzachte(a)infodisiac.com>
wrote:
> Pending Revisions conveys that publication is deferred, but not for
> what
> reason.
>
> Based on only the name it leaves a new editor guessing: maybe there
> is a
> server delay and the matter will resolve itself in next twenty
> minutes?
>
Yes, a new editor may ask "pending what exactly?" and the plural
"revisions" may bring frustration of thinking that there are many
revisions ahead of his/hers in the queue.
Pending Revisions conveys that publication is deferred, but not for what
reason.
Based on only the name it leaves a new editor guessing: maybe there is a
server delay and the matter will resolve itself in next twenty minutes?
Double Check or Revision Review tells clearly there is human intervention
needed for the next step.
Revision Review is my favorite. It seems more neutral, also less 'heavy' in
connotations than Double Check.
Also Review is clearly a term for a process, unlike Revisions.
compare
"This article is in Pending Revisions". or "Pending Revisions applies to
this article"
and
"This article is in Revision Review. " or "Revision Review" applies to this
article.
the latter sounds more natural to me.
There is only so much one can convey in two words without further
explanation.
So a new editor will not have a clue from the name what the review process
entails.
At least it is clear it is a process, and human intervention is key.
Erik Zachte
wiki-list(a)phizz.demon.co.uk writes:
Across the world the "Nobody is home" argument is quickly running out of
> steam. Google execs sentenced to 6 months in Italy, LimeWire guilty for
> its user's piracy, and blog owner found liable for user submitted libel.
>
It helps to actually read the stories and understand the cases. The Google
execs were found guilty even though they quickly responded to a complaints
and removed the offending video. In other words, they didn't make the
"nobody is home" argument.
Limewire is a contributory-infringement case that has nothing to do with
publisher liability. (Limewire distributed software.)
And the blog owner actually hasn't been found liable for user-submitted
libel in the Register story published. As the story is reported, the blog
owner has merely been told that moderation of content runs the risk of
*creating* liability by removing the exemptions for mere hosts. The decision
is regarding a pre-trial motion. In other words, the case has precisely the
opposite meaning of what wiki-list writes here, since it focuses on the
risks of moderation, not the risks of non-moderation.
But don't take my word for it -- read the links yourself!
>
>
> http://www.theregister.co.uk/2009/11/26/google_italy_trial
> http://www.theregister.co.uk/2010/05/18/limewire_copyright_ruling
> http://www.theregister.co.uk/2010/04/08/user_comments_ruling
>
>
I wouldn't endorse wiki-list's unusual interpretation of the cases, as
summed up here:
> the days of the internet being a free for all are coming to an end. If
> websites won't take responsibility, at least to the extent of having a
> policies in place which are enforced, then others will make it for them,
> by disabling access to the site.
>
With regard to the Google case, at least, it looks like taking
responsibility doesn't protect you, and with regard to the libel case,
moderation increases your risk of liability by undermining your statutory
exemption.
--Mike
What I'm advocating for now is voluntary compliance, for the following
reasons (and nobody has tried to address #3 yet):
It's a proven system of record keeping that verifies information like
names of subjects, stage names, date of birth, name of photographer,
consent (implied by completing affidavit), and the date the photos
were taken.
The legal responsibility for the accuracy and content of 2257 records
remains with the record holder, and personal identifying information
of the subjects of the photos (and the legal responsibility) remain
off-wiki.
It fulfills the licensing requirements of Creative Commons, saying
that our images must be made available for commercial use, however
currently our pornographic images CAN NOT be reused legally in the US
for commercial purposes because they lack USC 2257. This falls way
short of our "free content" ideals (as well as Commons:Licensing).
All primary producers (photographers) and secondary producers
(uploaders) of pornographic images in the US must keep records, even
if the images were uploaded to Commons by using a pseudo-anonymous
username. For this reason, sexual content transferred from Flickr
without 2257 information should not be accepted.
On Sat, May 22, 2010 at 2:13 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
> Hi everyone,
>
> I'm preparing a patch against FlaggedRevs which includes changes that Howie
> and I worked on in preparation for the launch of its deployment onto
> en.wikipedia.org . We started first by creating a style guide describing
> how the names should be presented in the UI:
> http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_rev…
[snip]
I'm concerned that the simplified graphical explanation of the process
fosters the kind of misunderstanding that we saw in the first slashdot
threads about flagged revision... particularly the mistaken belief
that the process is synchronous.
People outside of the active editing community have frequently raised
the same concerns on their exposure to the idea of flagged revisions.
Common ones I've seen "Won't people simply reject changes so they can
make their own edits?" "Who is going to bother to merge all the
unreviewed changes on a busy article, they're going to lose a lot of
contributions!"
None of these concerns really apply to the actual implementation
because it's the default display of the articles which is controlled,
not the ability to edit. There is still a single chain of history and
the decision to display an article happens totally asynchronously with
the editing.
The illustration still fosters the notion of some overseeing
gatekeeper on an article expressing editorial control— which is not
the expected behaviour of the system, nor a desired behaviour, nor
something we would even have the resources to do if it were desirable.
In particular there is no per-revision analysis mandated by our
system: Many edits will happen, then someone with the right
permissions will look at a delta from then-to-now and decide that
nothing is terrible in the current version and make it the displayed
version. It's possible that there were terrible intermediate
versions, but it's not relevant.
I have created a poster suitable for distribution to journalists
http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection.png
(Though the lack of clarity in the ultimate naming has made it very
difficult to finalize it. If anyone wants it I can share SVG/PDF
versions of it).
Due to numerous requests we have extended the submission deadline for
Wikimania 2010 as follows:
* Abstract Registration: May 24, 11.59 p.m. (Pacific Time)
* Notification for workshops: May 29, 11.59 p.m. (Pacific Time)
* Notification for panels, tutorials, presentations: June 3, 11.59
p.m. (Pacific Time)
See the Call for Participation for more details:
http://wikimania2010.wikimedia.org/wiki/CFP
Thank you for helping make Wikimania 2010 a successful event. :-)
See you in Gdansk, July 9-11!
With best regards,
Wikimania Team
--
Casey Brown
Cbrown1023
In a message dated 5/22/2010 11:41:53 AM Pacific Daylight Time,
wiki-list(a)phizz.demon.co.uk writes:
> <<The foundation or the site admins do moderate. The foundation or they
> DO
> have the power, to delete submissions that are considered non
> encyclopedic, trolling, libelous and etc. There is constant moderation
> on by or on behalf of the foundation. If not teh Foundation then the
> admins have responsibility. The foundation is not acting simply as a
> hosting site that merely stores user submitted data. It is not godaddy,
> it is not wordpress, it is not even YouTube.>>
*Any* user has the ability to delete content.
Is any user now "the foundation" ?
That's not an effective argument for the responsibility lying at the top,
in fact you've just made the complete opposite argument.
I was just about to post that same section.
From 2257(h)(2)(B)) exception to record keeping:
(v) the transmission, storage, retrieval, hosting, formatting, or
translation (or any combination thereof) of a communication, without
selection or alteration of the content of the communication, except
that deletion of a particular communication or material made by
another person in a manner consistent with section 230(c) of the
Communications Act of 1934 (47 U.S.C. 230 (c)) shall not constitute
such selection or alteration of the content of the communication;
What I would define as "communication" is the image page created by
the logged in user. That user created to page, selected and uploaded
(inserted) the image onto Wikimedia's servers. That person could be
viewed as a primary (if own image) or secondary (if transferred image)
producer. These individuals need to follow 18 USC 2257 record keeping
guidelines.
From there, volunteers (like myself) tag, categorize the page, and
start Deletion Requests (likely acceptacle under the Good Samaritan
clauses of (47 U.S.C. 230 (c)).
However, when that image is selected for reuse (and not in an
automated way, but by an actual human) on an article page, user page,
or off-wiki that person also becomes a secondary producer.
2257B(g) simply refers to 2257(h) above, so I'm not sure why Mike even
mentioned it.
(g) As used in this section, the terms “produces” and
“performer” have the same meaning as in section 2257 (h) of this
title.
On May 21, 2010, at 9:13 PM, Mike Godwin <mnemonic(a)gmail.com> wrote:
> 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
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
