> He he he... Wy bad, that was the completly wrong list! The naming scheme
> on these lists are to similar.
> It should go to our internal list at WM Norway. Its an on-going
> discussion about implementation details for a joint effort between WM
> Norway and a company that sells access to news paper archives, and the
> discussion are about how active wikipedians can have free access.
> What the heck, its already on our signpost and has been for some time!
> But for the continued discussion, the list wikino-l(a)lists.wikimedia.org
> or wikimedia-no-styre(a)lists.wikimedia.org would be a better place... ;)
>
> John (which spanks himself for being so sloppy)
>
Det som ble diskutert. I det store og hele er det nokså likt det som
allerede er kjent. Er alle enige før det går som en orientering på
e-postlista? Det ligger også noe på Tinget, men der sier jeg ikke så mye
om hvem som konkret er involvert og hvordan det her skal være lønnsomt
for Retriever. En må vel være nokså trangsynt om en ikke ser at de
driver butikk, og til og med tjener bra på drift av avisarkiv. ;)
John
---------
Det er dialog med Retriever, et firma som driv med nettscanning og
arkivtenester, om å åpne for tilgang slik at Wikipedias skribenter kan
søke og lese gratis i artikkelarkivet Atekst. Det er ikke intensjoner om
fri tilgang for lesere. Foreløpig er bokmål, nynorsk og samisk mest
aktuelle, men det snakkes også om svensk. Dette avisarkivet er det
største søkbare digitalarkivet av denne typen i Norge. De har også en
betydelig aktivitet i andre nordiske land. Skal vi gå i et samarbeid så
forutsetter det at løsningene blir generelle slik at andre aktører kan
"hekte seg på".
WM Norge kommer til å bli samarbeidspart i det her ovenfor Retriever om
vi klarer å bli enige. Marius og Pål kommer vel til å bli de sentrale
fra oss i å formulere vilkårene for et samarbeid, muligens med hjelp fra
WM Foundation. På den tekniske siden blir undertegnede (John) involvert.
Hos Retriever er Anders Eriksen kontakt inntil videre på det
administrative, Tomas Stenborg og Carl Anton Holmboe på det tekniske.
Initielt kommer det nok ikke til å bli arbeidet med mer enn en
hovedsammarbeidspart i pilotprosjektet, en del andre er spurt, men disse
er avventende inntil det kommer resultater fra arbeidet med Atekst.
Piloten vil bruke en metodikk for pålogging som er velkjent og
fungerende, men det kan bli aktuelt å se på andre metoder. OpenID er
nevnt tidligere, men ikke av noen av aktørene i markedet.
Økonomien i det her er tenkt slik at Atekst, eller andre avisarkiver,
får en trafikk som følge av at Wikipedia får fungerende referanser til
aviser. Dette gjør det svært viktig for de som selger tilgang til slike
avisarkiver at referansene er der og er korrekte. Det er det primære
incitamentet for dem til å gi oss gratis adgang. For oss er det primære
incitamentet å kvalitetssikre våre artikler ved å angi korrekte
referanser som vi og våre lesere kan bruke.
La meg presisere at vi er i en _dialog_ om det her og at ikke noe er
endelig. I tillegg må de enkelte prosjektene selv finne ut om de vil bli
med på et slikt samarbeid.
Så til det tekniske
Vi må definere hva vi mener med en "aktiv skribent", da en slik vil få
tilgang til tjenesten. Mitt forslag er at 500 bidrag eller
autopatruljert på bokmålsutgaven, eventuelt writer for FlaggedRevs, og
at i tillegg kan brukere som har mer enn 10 bidrag i løpet av siste døgn
få tilgang. Tilgangen blir stoppa om vedkommende blir blokkert.
Det finnes noen eksisterende API'er for hvordan en bruker gis tilgang
til Atekst, og ett av de består av en liten tekstfil med pålogginfo som
pakkes ned med GPG (nøkkelpar med offentlig og privat nøkkel) og sendes
over som en redirect på en get-request. Dette fungerer som et
ihendehaverdokument som gir en tidsbegrenset tilgang til å logge seg på.
Etter at brukeren er pålogget vil vedkommende bli sporet inne på Atekst
via cookies. Dette er en form for pålogg og brukersporing med kjente
feil og mangler, men den er tilgjengelig og er vurdert som tilstrekkelig
av Retriever og deres partnere.
Den formen for tilgangskontroll brukes i dag fra skoler, høyskoler og
universiteter over store deler av Norge. I utgangspunktet er det eneste
vi trenger å overføre en ident «wikipedia», men da må vi gjøre all
filtrering av aktuelle brukere på vår side. Trafikken kan gå kryptert
eller signert avhengig av hva brukere mener er riktigst, signering har
vel mest interesse om noen er så paranoide at de tror det overføres
hemmelig informasjon om dem, men jeg ville vel foretrekke full kryptering.
Piloten er satt opp slik at en logger på tjenesten ved å klikke på en
knapp på en spesialside. På denne siden blir det angitt hva informasjon
som avgis, og muligens hva informasjon som er brukt for å sjekke om
brukeren får tilgang. For tilfellet med Atekst så blir det oversendt
informasjon om ip-adresse, tidspunkt og brukerid i Atekst - det vil si
«wikipedia». Deretter arbeider en inne i Atekst for å finne artikler.
Det vil også være mulig å lese enkeltartikler ved å følge lenker, en
Digital object identifier eller lignende, som går via en spesialside og
lister tilbydere av artikler utfra denne. Dette blir på samme måte som
for ISBN-nummer og hvordan disse brukes på Spesial:Bokkilder, men hvor
vi i noen «artikkelkilder» har gratis tilgang. I dette tilfellet vil det
i tillegg til de tidligere angitte verdiene overføres en slik
artikkelidentifikasjon.
Fase 1 er å kunne logge på anonymt i Atekst, og dette er forsåvidt løst.
Den eneste usikkerheten er hvordan valg av testvektorer vil påvirke det
totale antall leste artikler. Vi ønsker at en «Friman» som kun jobber
med spesielle artikler skal få tilgang, selv om han ikke har skrevet noe
vesentlig på lang tid, mens en tilfeldig passerende ikke skal kunne
sette inn et mellomrom på en side og så få tilgang. Tjenesten er
relativt kostbar og vi må sikre oss at bruken understøtter
innholdsproduksjon og kvalitetssikring hos oss.
Fase 2 er å kunne lage «lenker» til avisarkiv, men dette er langt
vanskeligere fordi det ikke finnes noen entydig måte å identifisere
avisartikler. Bøker identifiseres på ISBN-nummere, og seriepublikasjoner
på ISSN-nummere, men det finnes ikke noen universell identifikator for
avisartikler. Historisk ble artikler identifisert i Atekst med
<publikasjon><dato><løpenummer>, hvor publikasjon var en trebokstavkode
og resten var tall. Nå er publikasjon gjort nummerisk og resten er et
løpenummer. Som en spesiell løsning mot Atekst vil dette fungere. Min
ide er å gjøre hele identifikatoren om til en DOI og la de som eier
publikasjonen definere hvem de lar sette på løpenummer. Det betyr at
Atekst definerer løpenummer for de kildene de har, men at det må skje
noe mapping mellom de formelle produktid'ene og deres interne
kildeid'er. Men altså, her er det et problem hvis vi skal lage en
generell løsning - vi ønsker ikke en spesiell løsning kun for Atekst men
noe alle arkiv kan bruke.
Som et alternativ kan vi lage noe som syntetiserer en lenke utfra
publikasjon, dato, side og tittel, men dette blir spesifikt for det
enkelte arkiv og ikke helt pålitelig. I Atekst finnes det et API som vi
kan bruke. Da vil en klientapplikasjon i nettleseren detektere bruk av
malen "Kilde artikkel" og lage en spørring ved behov til toolserver
(tools.wikimedia.de) som så igjen lager en spørring til Atekst. Når
klientapplikasjonen har en identifikator kan de vanlige mekanismene
brukes. Den lange omveien er for å skjule brukerens reelle identitet, og
samtidig gjøre det mulig for Retriever å forholde seg til en enkelt
ip-adresse. En returnert identifikator kan brukes for oppslag i
konkurrerende arkiv så lenge de støtter samme type identifikator. Noe
lignende kan vi gjøre for bøker i for eksempel Bibsys om vi får lov av
disse.
Det er kjent at om vi setter i drift fase 1 uten samtidig å ha på plass
fase 2 så vil det oppstå en situasjon hvor det skjer en lekkasje av
brukeridentifisering fra oss og til Atekst ved at brukernavn på
Wikipedia kan kobles mot IP-adresse via referer og historikk for
redigeringer. Det skjer imidlertid allerede med de eksisterende
løsningene og er antakeligvis ingen showstopper i seg selv. Det blir
imidlertid sett på løsninger for fase 2 som gir økt sikkerhet mot denne
informasjonslekasjen, selv om de ikke er fullgode.
Fase 3, som er litt i det blå, og på siden av det som er det primære
ovenfor Retriever, er å lage en løsning som gjør at artikler ikke
forsvinner for oss når de blir arkivert. Dette er spesielt viktig for
artikler på webutgavene. Målet her er å gjøre det vesentlig enklere å
høste inn metadata, inklusive data som angir nødvendige identifikatorer,
og forenkle prosessen med påføring av referanser. Håpet er at istedenfor
en <ref> med den store stygge malen "Kilde www" så kan vi skrive
{{REF:url}}, {{REF:doi}} eller {{REF:isbn} og automatisk få alle
metadata om tittel og forfatter og alt annet rask. Skal vi få til dette
så må flere på banen, ikke bare Retriever, selv om en demo av dette
allerede funger "sådär".
I det siste er det gjemt et nokså betydelig problem, og det går på bruk
av referanser til flyktige nettssider. Når vi bruker en referanse til en
slik nettsside så ønsker vi å lage en arkivkopi. Dette har vi lov til
for internt bruk, men vi ønsker ikke internt bruk, vi ønsker å vise hva
vi brukte den til og vi ønsker å vise den til andre. Slik åpen
arkivering er ikke uten videre tillatt i alle land, og i Norge er slikt
et problem.
Fremdrift i det her er at fase 1 bør ha en fungerende pilot i løpet av
fjerde kvartal, og fase 2 kommer deretter. Det er ingen tidsplan for
fase 3. Tidsplaner i frivillige prosjekt er uansett, vel, frivillige.
John Erling Blad
no:user:jeblad
This is in response to SirFozzie's (David Yellope) comments below. I
waited to respond until all of the evidence had been collected and
reviewed.
>from sirfozzie(a)gmail.com
>I've received information on the issue with Mr. Merkey attempting to get
another user fired from his real life job.
>To the best of my ability, I've confirmed that Mr. Merkey HAS called
another Wikipedia user's work superior twice (in June and again,
recently) >in an attempt to harass that user with spurious complaints.
>Mr. Merkey is currently in the 13th month of a one year English Wikipedia
ban (reset several times due to ban evasion via IP Addresses). I have
forwarded the information I've received to the English Wikipedia
>Arbitration
>Committee for use there, or at the OFFICE/FOUNDATION level.
>I think at this point, the best policy with regards to Mr. Merkey, is to
politely request to him that if he has any further wish to communicate with
>or about Wikipedia, that he do so privately and via his representative.
_______________________________________________
>foundation-l mailing list
>foundation-l[at]lists.wikimedia.org
>Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
David,
I recorded the telephone conversations with Paul Fagerburg's employer and
I want you to know, at no time did I ever ask that Paul be fired, in fact,
I asked he NOT be fired and I called to inform them that IP addresses
originating from their location were involved in off-wiki harassment.
This is no different than Wikipedia sending abuse reports regarding
vandalism.
You also should consider the fact that Paul's employer is liable for the
misuse of their network, and its unlikely they will admit their liablity,
so I do not believe you and if they said this they are lying and I can
prove it.
I discussed this situation with Mike Godwin and have been advised to
obtain a civil stalking injunction to halt this abuse against ALL editors
who participated. Three separate numbers called and harassed Mr. Aguilar.
One of them has been verified to be Paul Fagerburg. Given the fact that
yourself, William McKinney, and another editor placed into an oversighted
edit summary "your company switchboard seems to think otherwise" then
later Paul Fagerburg posts to Wikipedia a retraction (after calling them
again) "well they said he used to work there" after he called them again
and they told him I NEVER worked there, leads to the inescapable
conclusion you and others were involved in this. The icing on the cake
is Werdna posting a page stating "do not unblock merkey without fagerburgs
permission".
Thanks for making the case Wikipedia is nothing more than an online
stalking mill and its admins act in concert with stalkers to harrass users
-- even when they are not editing on the site. Wikipedia needs to clean
up its act.
This is a formal notice that the following individuals will be served with
a civil stalking injunction for participating in off-wiki telephone
harassment:
Paul Fagerburg
David Yellope
William McKinney
Wikimedia is advised these users are the subject of legal action for
engaging in criminal stalking and telephone harassment in violation of
Utah Codes 76-09-201 http://le.utah.gov/~code/TITLE76/htm/76_09_020100.htm
and 77-3a-101 http://le.utah.gov/~code/TITLE77/htm/77_03a010100.htm.
Legal action has been initiated in the 4th Judicial District Court for
online stalking and harassment.
Posting of banning notices or any other form of harassment may result in
other editors being the subject of further action since these actions
violate Utah Codes 76-09-201
http://le.utah.gov/~code/TITLE76/htm/76_09_020100.htm -- its online
harassment. The arbcom is not immune.
You people leave me alone and I leave you alone.
Jeff
How about we just ignore him?
----- Original Message ----
From: Nathan <nawrich(a)gmail.com>
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Sent: Tuesday, September 23, 2008 6:58:32 AM
Subject: Re: [Foundation-l] Jeff Merkey Fiasco on English Wikipedia
Is it possible to have *(a)wolfmountaingroup.com moderated or blacklisted so
that Foundation-l doesn't continue to serve as a forum for this individual?
No useful purpose is served by allowing him to post such letters.
Nathan
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
There is a proposal to enable the Nuke extension for most wikis at Metapub:
http://meta.wikimedia.org/wiki/Metapub#Enable_mw:Extension:Nuke_on_WMF_wikis
_by_default
The extension (http://www.mediawiki.org/wiki/Extension:Nuke) allows sysops
to mass-delete recent page creations by a single user. So for spambots and
page creation vandals, this speeds up deleting their pages. It won't delete
old pages, and it won't delete an arbitrary list of pages - only recent
ones, and only pages by a single user. While the extension is powerful, it
doesn't give admins any abilities they don't already have.
Part of the proposal is that some wikis (probably large ones) will want to
decide for themselves - if your home wiki falls into that category, then
perhaps it should be added to the list of wikis which will not be affected.
Please consider that this will be useful for the small wikis where stewards
may need to mass-delete pages by a spambot/vandal - the intent is not to
force wikis with communities to have this extension. Such communities should
not be included in the proposal (but I don't know which ones those are, so I
need your help to list them).
Thanks,
Mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I could not find this in the privacy policy... however, what is
Wikimedia's current data retention policy? That is to ask, how long do
projects keep data for use in tools such as checkuser?
- --
Best,
Jon
[User:NonvocalScream]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjIhc0ACgkQ6+ro8Pm1AtVW/QCgrCy1HajtTeGCRBcxD/ZRZxDk
l8oAniHizNJEpEXKhBIBqg9rIlnqhIRJ
=mqSc
-----END PGP SIGNATURE-----
It's the season for books about Wikipedia!
I am very pleased to announce that "How Wikipedia Works", by myself
(Phoebe Ayers), Charles Matthews, and Ben Yates has now been published
by No Starch Press.
You can view a table of contents and find more information here:
http://nostarch.com/wikipedia.htm
We cover the background of Wikipedia and the motivations and core
values behind the project, how to edit existing articles and develop
new ones, policies and guidelines for content and editing, how the
editing community works, and how to get involved in the community.
Although we focus on the English-language Wikipedia, we also cover the
wider world of other language Wikipedias, the Wikimedia Foundation,
and Wikipedia's sister projects. We hope the book will be useful both
as a reference for current contributors and as a comprehensive
introduction to Wikipedia and the Wikimedia projects for newbies.
The book is licensed under the GFDL, and an online version will be
forthcoming shortly. Any printed copies purchased will help support
traditional publishers using free licenses successfully, and 5% of the
authors' royalties will be donated to the Wikimedia Foundation.
We very much look forward to the community's feedback! For now, you
can leave comments on the wiki here:
http://wiki.phoebeayers.info
or email or leave a talk page message for any of us.
Many thanks to everyone who helped us out with this, particularly the
folks at No Starch press who were very supportive of developing a
free-content work; Benjamin Mako Hill, who provided technical and
licensing support; and SJ Klein, who helped develop the book.
best,
Phoebe ([[en:user:phoebe]])
--
* I use this address for lists; send personal messages to phoebe.ayers
<at> gmail.com *
Recently i have been lurking around many smaller WMF projects. (When i
say "smaller", i refer to Wikipedias which are smaller then the
biggest ones - yes, that means almost all Wikipedias - and to
non-Wikipedia projects in languages which have an established
Wikipedia, as they are usually smaller than the Wikipedia in the same
language.)
One worrying thing that i noticed is that in some of these projects
there is no strict adherence to GFDL-only text. Since my first day in
Wikipedia i understood how important the GFDL is. I understood that
articles cannot be copied verbatim even from sources whose copyright
terms allow copying for non-commercial usage, because the "free" in
"The Free Encyclopedia" does not refer only to price.
There is, however, a de-facto consensus in most projects that non-text
media (images, sounds) can be uploaded as fair use (es.wiki is a
notable exception). PLEASE READ FURTHER: THIS EMAIL IS NOT A PROTEST
AGAINST FAIR USE IMAGES.
What i started noticing recently is that certain projects allow TEXT
which is GFDL-incompatible.
For example, a certain Wikipedia admits to taking certain texts from
copyrighted sources which allow verbatim copying if the source is
cited, but not free modification. Their rationale is that their
language is under-privileged and has few proficient volunteer writers.
Another Wikipedia has a template on thousands of articles saying that
they were copied from a copyrighted online encyclopedia and asks the
editors not to enhance them. (I have to admit that i have limited
understanding of this language, but i'm pretty sure that i got this
one correctly.) Unlike in the first example, this is a very well
established literary language with millions of educated writers.
A Wikisource in another language accepts texts which are outright
copyrighted "by a special arrangement with the publisher, which
allowed their free (as in beer) publication in Wikisource".
Does the foundation allow autonomy in such matters to projects? I
believe that it is not the case.
I intentionally don't name the languages, because i don't really want
to act like a cop, especially not in a community of which i am only a
lurker.
I do ask the Foundation this: If the GFDL is important to WMF, please
have some serious WMF representative reiterate the importance of GFDL
to the apparent leaders of ALL projects, not just Wikipedias.
Of course, if the GFDL is not important to WMF, then forget it...
--
Amir Elisha Aharoni
heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com
cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com
"We're living in pieces,
I want to live in peace." - T. Moore
It is inevitable we have to use scientific tools, one of them is the Ausbausprache - Abstandsprache - Dachsprache criterion.
http://en.wikipedia.org/wiki/Ausbausprache_-_Abstandsprache_-_Dachsprache
GerardM you critized the subjectivity of the clause "Sufficiently unique", Why do not add scientifical criteria in the community draft?
C.m.l.