Re: [Wikimedia-l] [Wikimedia Announcements] Announcing a new Wikimedia project: Abstract Wikipedia

[C. Scott Ananian]

If "anti-classist" is your way of writing "empowering the less-powerful",
then sure.  As the rest of my email indicates, I'm choosing to focus on
language and language groups, since that's the most direct relation to the
output and input technologies of Abstract Wikimedia.  Obviously there is no
direct mapping from 'race' to language, although those are both social
constructs.  I found the academic work of the anti-racism movement helpful
in thinking about efforts to counteract long-standing structural
privileges, but if you prefer to use a different framework feel free.  It
seems we are aligned on the actual actions required.
  --scott

On Thu, Aug 6, 2020 at 3:42 AM James Salsman  wrote:

> Scott,
>
> It is perfectly legitimate to be "anti-racist," but races are completely
> artificial constructs. Racial conflict was interposed during the "tea
> party" astroturfing in response to the Occupy movements:
>
>
> https://www.reddit.com/r/occupywallstreet/comments/hyoogt/is_this_accurate/fze7t5c/
>
> Do you support Wikimedia Foundation AI being programmed to be explicitly
> anti-classist?
>
> Best regards,
> Jim
>
>
> On Wed, Aug 5, 2020 at 12:19 PM C. Scott Ananian 
> wrote:
>
>> Sorry I'm coming to this discussion a bit late, but I'd like to underline
>> a
>> slightly different aspect of the concern that Phoebe raised:
>>
>> > It concerns me that, at least in the high-level project proposals I've
>> > seen (I haven't been tracking this closely, and haven't read the
>> academic
>> > papers) I have not yet seen discussions of ethical data, or how we might
>> > think about identifying bias, or even how to recruit contributors and
>> the
>> > impact on existing contributors.
>> >
>>
>> Using the terminology of Ibram X. Kendi (and others), I'd put this as:
>> "it's not enough to not be racist, you must actively be *anti-racist*."
>>
>> Abstract Wikipedia is a "color blind" project.  Indeed it is often
>> described as advancing WMF goals by improving the amount of content
>> available for minority languages.
>>
>> However, it is built on a huge edifice of ML and AI technology which
>> advantages majority languages and the already-powerful.
>>
>> As Phoebe mentioned, the subtle biases of ML translation toward majority
>> views (selecting the "proper" gender pronoun for someone described as a
>> "doctor" or "professor", say) are well known, and certainly deserve to be
>> foregrounded from the start, as Danny has pledged to do in his response to
>> Phoebe.
>>
>> But the infrastructure of this project is built this way from the ground
>> up.  Language models for European languages are orders of magnitude better
>> than language models for minority languages (if the latter exist at all).
>> The same is true for ontologies and every other constructed abstraction,
>> down to choices of what topics are significant enough to include in an
>> abstract article---but that ground has been ably covered by Kaldari and
>> others.  So let me concentrate solely on language models in the remainder
>> (with some parenthetical asides, for which I hope you'll forgive me).
>>
>> I would like to challenge Abstract Wikipedia not only to be "not racist"
>> or
>> "color blind", but to be actively *antiracist*.  That is, instead of
>> passively accepting the status quo wrt language models (& etc), to commit
>> to actively supporting a language model in *at least one* minority
>> language, treating it as a first-class citizen or (better) the *main*
>> output of the project.  That means not just looking for "a good enough
>> language model that happens not to be a European language" but *actively
>> developing the language model* so that the Abstract Wikipedia project
>> *from
>> inception* has a positive effect on *at least one* community speaking a
>> underrepresented language with a small Wikipedia.  (Again, WLOG this could
>> apply to general AI/ML support for many many minority groups, but I'm
>> sticking with "at least one" and "language model" in order to make this as
>> concrete and actionable as possible.)  This of course also means
>> committing
>> to hire a speaker of that non-European language as part of the core team
>> (not just an "and translations" afterthought), committing to foregrounding
>> that language in demonstrations, and doing outreach and community building
>> to the language group in question.  (All the mockups I've seen have been
>> in
&g

Re: [Wikimedia-l] [Wikimedia Announcements] Announcing a new Wikimedia project: Abstract Wikipedia

[C. Scott Ananian]

Sorry I'm coming to this discussion a bit late, but I'd like to underline a
slightly different aspect of the concern that Phoebe raised:

> It concerns me that, at least in the high-level project proposals I've
> seen (I haven't been tracking this closely, and haven't read the academic
> papers) I have not yet seen discussions of ethical data, or how we might
> think about identifying bias, or even how to recruit contributors and the
> impact on existing contributors.
>

Using the terminology of Ibram X. Kendi (and others), I'd put this as:
"it's not enough to not be racist, you must actively be *anti-racist*."

Abstract Wikipedia is a "color blind" project.  Indeed it is often
described as advancing WMF goals by improving the amount of content
available for minority languages.

However, it is built on a huge edifice of ML and AI technology which
advantages majority languages and the already-powerful.

As Phoebe mentioned, the subtle biases of ML translation toward majority
views (selecting the "proper" gender pronoun for someone described as a
"doctor" or "professor", say) are well known, and certainly deserve to be
foregrounded from the start, as Danny has pledged to do in his response to
Phoebe.

But the infrastructure of this project is built this way from the ground
up.  Language models for European languages are orders of magnitude better
than language models for minority languages (if the latter exist at all).
The same is true for ontologies and every other constructed abstraction,
down to choices of what topics are significant enough to include in an
abstract article---but that ground has been ably covered by Kaldari and
others.  So let me concentrate solely on language models in the remainder
(with some parenthetical asides, for which I hope you'll forgive me).

I would like to challenge Abstract Wikipedia not only to be "not racist" or
"color blind", but to be actively *antiracist*.  That is, instead of
passively accepting the status quo wrt language models (& etc), to commit
to actively supporting a language model in *at least one* minority
language, treating it as a first-class citizen or (better) the *main*
output of the project.  That means not just looking for "a good enough
language model that happens not to be a European language" but *actively
developing the language model* so that the Abstract Wikipedia project *from
inception* has a positive effect on *at least one* community speaking a
underrepresented language with a small Wikipedia.  (Again, WLOG this could
apply to general AI/ML support for many many minority groups, but I'm
sticking with "at least one" and "language model" in order to make this as
concrete and actionable as possible.)  This of course also means committing
to hire a speaker of that non-European language as part of the core team
(not just an "and translations" afterthought), committing to foregrounding
that language in demonstrations, and doing outreach and community building
to the language group in question.  (All the mockups I've seen have been in
German and English, and have been pitched to an English-speaking audience.)

I don't think it is wise in 2020 to pretend that "colorblind" business as
usual will advance the goals of our organization.  We need to actively work
to ensure this project has effects that *work against* the significant
pre-existing biases toward highly-educated speakers of European languages.
It is not enough to say that "someday" this "may" have an effect on
minority language groups if "somebody" ever gets around to doing it.  We
must make those investments proactively and with clear intention in order
to effect the change we wish to see in the world.
  -- C. Scott Ananian
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Statement by Wikimedia Board on Healthy Community Culture, Inclusivity, and Safe Spaces

[C. Scott Ananian]

I hope to continue this discussion, focusing on technical
features/UX/affordances, at the 2017 Dev Summit in January.  I welcome
comments & ideas at https://phabricator.wikimedia.org/T149665.
  --scott

On Thu, Dec 8, 2016 at 3:18 PM, Christophe Henner 
wrote:

> Hello everyone,
>
> As many of you know, over the past couple of years the Wikimedia Foundation
> has taken a focused look at community health—particularly in regards to
> harassment. The Foundation's Board has been monitoring and discussing this
> issue over the past year with great interest. We have prepared a statement
> offering our thoughts on this topic, and providing a clear mandate for the
> Foundation’s leadership to fully engage on this issue.
>
> Our statement is below and has been posted on Meta-Wiki, where it is set up
> for translation:
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_
> Board_noticeboard/November_2016_-_Statement_on_Healthy_Community_Culture,_
> Inclusivity,_and_Safe_Spaces
>
> Since the Foundation was established, we have been invested in building a
> positive community culture. As part of these efforts, we have monitored the
> projects for instances of harassment, escalating our capacity to respond in
> recent years. Thanks to the work of the Foundation's Support and Safety
> Team, we now have data in the form of the 2015 Harassment Survey[1] about
> the nature of the issue. This has enabled us to identify key areas of
> concern, and step up our response appropriately. This research shows that
> harassment has a negative impact on participation in our projects. This has
> implications for our ability to collect, share, and disseminate free
> knowledge in support of the Wikimedia vision. Our statement speaks to the
> Board's duty to help the Foundation fulfill its mission.
>
> The Board is committed to making our communities safer and will not accept
> harassment and toxic behavior on Wikimedia projects. We believe this matter
> deserves the Foundation's attention and resources, and have confirmed this
> responsibility at our latest Board meeting on November 13th. The questions
> that lay before us all now are how to best address this threat, rather than
> if we should attempt to do so.
>
> The Board especially appreciates and applauds the work being done to
> address this important issue by many community leaders across the movement
> and teams within the Foundation. We look forward to seeing this cooperative
> work not only continue, but expand. Finally, we encourage everyone who is
> interested in helping the Foundation address this threat to our vision and
> mission to engage in the upcoming discussions around this issue.
>
> On behalf of the Wikimedia Foundation Board of Trustees,
>
> Christophe Henner, Board Chair
>
> María Sefidari, Board Vice Chair
>
> [1] https://meta.wikimedia.org/wiki/Research:Harassment_survey_2015
>
>
> Statement by the Wikimedia Board on Healthy Community Culture, Inclusivity,
> and Safe Spaces
>
>
> At our Board meeting on November 13, and in Board meetings in September and
> June, we spent considerable time discussing the issues of harassment and
> hostility on the internet generally, and more specifically on the Wikimedia
> projects.
>
> This is an important issue. Approximately 40% of internet users, and 70% of
> women internet users, have personally experienced harassment.[1] Of people
> who have reported experiencing harassment on Wikimedia projects, more than
> 50% reported decreasing their participation in our community.[2] Based on
> this and other research, we conclude that harassment and toxic behavior on
> the Wikimedia projects negatively impacts the ability of the Wikimedia
> projects to collect, share, and disseminate free knowledge. This behavior
> is contrary to our vision and mission.
>
> Our communities deserve safe spaces in which they can contribute
> productively and debate constructively. It is our belief that the Wikimedia
> Foundation should be proactively engaged in eliminating harassment,
> promoting inclusivity, ensuring a healthier culture of discourse, and
> improving the safety of Wikimedia spaces. We request management to dedicate
> appropriate resources to this end.
>
> We urge every member of the Wikimedia communities to collaborate in a way
> that models the Wikimedia values of openness and diversity, step forward to
> do their part to stop hostile and toxic behavior, support people who have
> been targeted by such behavior, and help set clear expectations for all
> contributors.
>
> [1] 2014 Pew Research Center Study, found at:
> http://www.pewinternet.org/2014/10/22/online-harassment/
>
> [2] 2015 WMF Harassment Survey, found at:
> https://upload.wikimedia.org/wikipedia/commons/5/52/
> Harassment_Survey_2015_-_Results_Report.pdf
>
>
>
> Christophe HENNER
> Chair of the board of trustees
> chen...@wikimedia.org
> +33650664739
>
> twitter *@schiste*skype *christophe_henner*
> 

[Wikimedia-l] Implementing Katherine's Vision: "Discussing Discussions"

[C. Scott Ananian]

A few weeks ago our Executive Director gave a talk on "Privacy and
Harassment on the Internet" at MozFest 2016 in London.  I encourage you to
read the transcript:

https://en.wikisource.org/wiki/Privacy_and_Harassment_on_the_Internet


Katherine argued that the Wikimedia project can take a lead role in
creating a culture of respect and inclusion online.  I whole-heartedly
agree, and I hope you all do too.  She concluded with:

"We have a lot of work to do. I know that. We know that. As Molly’s story
> illustrates, we are not there yet."


I'd like to open a broader discussion on how we get "there": how to
build/maintain places where we can get work done and control abuse and
vandalism while still remaining wide open to the universe of differing
viewpoints present in our projects.  We can't afford to create filter
bubbles, but we must be able to provide users safe(r) spaces to work.

By habit I would propose that this be a technical discussion, on specific
tools or features that our platform is currently missing to facilitate
healthy discussions.  But the "filter bubble" is a social problem, not a
technical one.  Our project isn't just a collection of code; it's a
community, a set of norms and habits, and a reflection of the social
process of collaboration.  A graph algorithm might be able to identify a
filter bubble and good UX can make countervailing opinions no more than a
click away, but it takes human will to seek out uncomfortable truth.

So although my endgame is specific engineering tasks, we need to start with
a broader conversation about our work as social creatures.  How do we work
in the projects, how do we communicate among ourselves, and how do we
balance openness and the pursuit of truth with the fight against abuse,
harassment, and bias.

Let's discuss discussions!

Here are some jumping off points; feel free to contribute your own:

We currently use a mixture of Talk pages, Echo, mailing lists, IRC,
Phabricator, OTRS, Slack, Conpherence, and Google Doc on our projects, with
different logging, publication, privacy/identity, and other
characteristics.  I tried to start cataloging them here:

https://lists.wikimedia.org/pipermail/wikimedia-l/2016-November/085542.html


Because of this diversity, we lack a unified code of conduct or mechanism
to report/combat harassment and vandalism.

Matt Flaschen replied in the above thread with an update on the Code of
Conduct for technical spaces:

https://lists.wikimedia.org/pipermail/wikimedia-l/2016-November/085542.html

...which should definitely help!  The creation of a centralized reporting
mechanism, in particular, would be most welcome.

I created a proposal for the Wikimedia Developer Summit in January
discussing "safe spaces" on our projects:

https://phabricator.wikimedia.org/T149665

Subscribe/comment/click "award token" to support its inclusion in the dev
summit or to start a conversation there.

I have another, broader, proposal as well, on the "future of chat" on our
projects:

https://phabricator.wikimedia.org/T149661

Subscribe/comment/click "award token" there if that angle piques your
interest.

It seems that "groups of users" arise repeatedly as an architectural
meta-concept, whether it's a group of collaborators you want to invite to
an editing session, a group of users you want to block or ban, a group of
users who belong to a particular wikiproject, or who watch a certain page.
We don't really have a first-class representation of that concept in our
code right now.  In previous conversations I've heard that people "don't
want  to turn into another facebook" and so have pushed
back strongly on the idea of "friend lists" (one type of group of users) --
but inverting the concept to allow WikiProjects to maintain a list of
"members of the wikiproject" is more palatable, more focused on the editing
task.  From a computer science perspective "friend list" and "member of a
wikiproject" might seem identical--they are both lists of users--but from a
social perspective the connotations and focus are significantly different.
But who administers that list of users?

Perhaps we can build a system which avoids grappling with user groups
entirely.  It was suggested that we might use an ORES-like system to
automatically suggest collaborators on an editing project based on some
criteria (like editing history), rather than force you or the WikiProject
to maintain an explicit list.  Perhaps you can implement block lists to
combat harassment based entirely on keywords, not users.  Do we trust the
machine to be more fair and less abusive than us mere mortals? Additional
ideas welcome!   (I don't have a dedicated phab task for this, but
https://phabricator.wikimedia.org/T149665 might be appropriate if you want
to contribute off-list.)


Hopefully this has been enough to prime the pump.

Let's discuss discussions.

Let's live up to the hope placed in us by the Washington Post:

Re: [Wikimedia-l] Editor safety and anonymity: ending IP address exposure?

[C. Scott Ananian]

On Thu, Nov 17, 2016 at 11:09 PM, Gergo Tisza  wrote:

>
> the ability to claim recent anonymous edits when you register.
>

Here, here.  I'm sure my IP address is lying around in lots of places in
the wikidump because I forgot to log in or my cookie expired and I never
noticed.  Automating the task of claiming those edits once you log in would
go far toward preventing accidental IP exposure.

I might also suggest thinking of this in terms of architectural change.  We
have been too casual about IP information inside mediawiki.  What if we
took as a first step factoring out all IP-related code from the core db and
pushing it into a separate db.  So instead of "IP edits" we have some sort
of automatically-generated pseudonym *but also recorded the IP address
associated with this pseudonym in a separate database* -- perhaps this
function is actually in an extension, not in core mediawiki.  Now we
preserve all our abilities to track down sock puppets or do IP blocks, but
at the cost of one indirection.

We can then take steps to further protect/limit/purge this IP address
database independent of the core mediawiki database, and we don't have
"hidden gotchas" in the core code because the core code doesn't manipulate
IPs any more.  And folks who do routine tasks like processing archive dumps
of the core db don't stumble across IPs.
  --scott

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] (no subject)

[C. Scott Ananian]

On Thu, Nov 17, 2016 at 10:30 PM, Pine W  wrote:

> As a reminder: IRC is governed by Freenode. Channels can have their own
> rules, and there are widely varying systems of internal governance for
> Wikimedia IRC channels. I think it's important to note that WMF and the
> Wikimedia community are guests on Freenode, and I'm uncomfortable with the
> proposition to extend a WMF policy into IRC channels without explicit
> consent from the ops of those channels; it seems to me that the TCC would
> be a per-channel opt-in on IRC, not a WMF blanket standard.
>
> Speaking more generally, I am wary of WMF encroachment into what I should
> be fundamentally community-governed spaces. I have not heard a lot of
> objections from the community to the proposed technical code of conduct,
> and I've heard some arguments for and against the rationale for having it;
> my main concern is that I would prefer that the final document be ratified
> through community-led processes.
>

I agree that changes here should involve heavy community participation,
which is a reason I'm trying to initiate broader discussion.

We have been moderately successful in "outsourcing" real time chat to a
third-party (IRC and Freenode) in the past, but it does leave us out of
control of what may become a fundamental technology for our platform.
Certainly we could simply embed a web-based IRC client in talk pages, for
instance.  That would continue the status quo. It's certainly one point in
the possible solution space, and I'm not foreclosing that.  I just think we
should discuss discussions holistically.  What are the benefits of
disclaiming responsibility for real time chat?  What are the benefits of
the freenode conduct policy?  What are the disadvantages?

We could also "more tightly integrate chat" without leaving IRC or
Freenode.  For the [[en:MIT Mystery Hunt]] many teams build quite elaborate
IRC bots that layer additional functionalities on top of IRC.  Matt's email
mentioned a "central reporting place".  We could certainly allow IRC
channels to opt-in to a WMF code of conduct and opt-in to running a WMF bot
providing a standardized and consistent reporting mechanism/block
list/abuse logger.  That's another point in the solution space.

My personal dog in the race is "tools".  I totally love community-led
processes.  But I am concerned that WMF is not providing the communities
adequate *tools* to make meaningful improvements in their social
environments.  Twitter rolled out a new suite of anti-abuse features this
week (https://9to5mac.com/2016/11/15/twitter-online-abuse-mute-features/)
so sadly the WMF platform is now behind twitter in terms of providing a
healthy working environment for our contributors.  We need to step up our
game.  As you note, the first step is this discussion involving the
community to take a broad look at discussions on our platform and determine
some basic social principles as well as architectural planks and
commonalities.  Hopefully we can then follow that up with an aggressive
development effort to deploy some new tools and features.  I believe this
will be an iterative process: our first tools will fall short, and we'll
need to continue "discussing discussions", revisiting assumptions, and
building improved tools.

But we can't allow ourselves to stand still.
 --scott

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] (no subject)

[C. Scott Ananian]

On Thu, Nov 17, 2016 at 5:32 PM, Andrew Lih  wrote:

> Love it or hate it, Facebook as a way of linking together Wikimedians
> across languages is a big plus (eg. projects like #100wikidays).
>

Ooh, man, you're pushing my hot button topics!  I proposed
https://phabricator.wikimedia.org/T149666 for the dev summit; my "big
picture" vision here is that we start using our machine translation tools
to tie our projects more tightly together, so we feel more like "one
project aided by a bunch of babel fish" and less like "a thousand separate
projects, each in their own tower".

So, bringing it back to chat -- and perhaps Shadow Namespaces (
https://phabricator.wikimedia.org/T149666) -- one goal might be to build
discussions into our platform in a way which can be cross-platform, with
integrated machine translation aids to allow near-seamless multilingual
conversations, thereby bridging barriers between our communities.  Of
course the vandalism and anti-harassment and user filter tools would need
to be multilingual in the same way...
  --scott

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] (no subject)

[C. Scott Ananian]

On Tue, Nov 15, 2016 at 3:36 AM, John Mark Vandenberg 
wrote:

> On Mon, Nov 14, 2016 at 11:37 PM, Dariusz Jemielniak 
> wrote:
> > Until we have better tech available, I want to assure you that I want to
> be
> > available, and apart from Meta, I gladly offer IRC or video
> conversations,
> > or other media, to whoever feels it may be useful (let's track this
> > committment of mine in the old-fashioned way for now).
>
> Rather than IRC or video, which both have significant problems for
> this type of open engagement, perhaps WMF could install a modern group
> chat system, like Zulip, or another Slack-like tool.
>
> The enthusiasm for Discourse hasnt resulted in any significant adoption.
> I venture to suggest that this is because it isnt mobile friendly, and
> doesnt integrate with MediaWiki authentication.
> Their app is little more than a web-browser (and the WMF labs instance
> doesnt support the necessary API anyway.)
> https://phabricator.wikimedia.org/T124691
> https://phabricator.wikimedia.org/T150733
>
> I've created a task about this problem for GCI and Outreachy which are
> about to start:
>
> https://phabricator.wikimedia.org/T150732
>
> I see Slack is being used by Portuguese Wikipedia
>
> https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Slack
>
> It would be good to hear their opinion on this tool?
>

I would love to have a broader discussion about communication in the
projects more generally.  As you know, we currently have a few mechanisms
(and please correct any mischaracterizations in the below):

 * Conversation in the Talk: namespace (either in raw wikitext or Flow)
- This is archived, and presumably subject to same code of conduct
guidelines as parent wiki.  It is public. Anonymous/IP editors are allowed.

 * Echo
- Unarchived transient notifications, very restricted by design.  Could
be made more general (but see below).

 * Conversation on mailing lists
- Also archived, often moderated.  Public, although you can always send
an unarchived private reply email to a particular sender.  Anonymity is
harder here, although possible with some effort.  Code of conduct is
"whatever the moderator will allow, if there is a moderator."

 * Conversation on IRC
- Deliberately not archived.  Intended for casual conversation and
informal negotiation.  Public, although not searchable after the fact
(unless you keep a private log).  Anonymity is fairly easy -- in fact, it
can be quite difficult to associate IRC nicks with on-wiki identities even
if all parties are willing.  No code of conduct, although there are ops who
can boot you (sometimes).

 * Phabricator
- Archived task-oriented discussions, leaving to a desired outcome.
Anonymous participation disallowed.  Search possible in theory; in practice
the implementation is quite limited.  Some (security-sensitive)
conversations can be private, but (AFAIK) an ordinary user does not have a
means to create a private conversation.  I'm not aware of an explicit code
of conduct.

 * OTRS
- Similar to Phabricator, except that by default all conversations are
private to OTRS staff and the submitter.  I'm not aware of an explicit code
of conduct, although this is mitigated by the fact that the conversations
are not public which limits the possibility of abuse.

 *  Slack on ptwiki, apparently?

 *  Conpherence as part of Phabricator.  (I don't have enough experience
with the last two to categorize them.)

We are missing currently missing:

  * Conversations anchored to specific editing tasks, like "comments" in
google docs.

  * Integrated conversation associated with an editing session (like the
integrated chat in google docs)

  * Integrated real-time chat -- like IRC, but anchored to on-wiki
identities, so I can send a "you still around and editing?" message before
reverting or building on a recent change.

  * Workflow-oriented chat.  Like the task-oriented chat in Phabricator,
but integrated with on-wiki activities such as patrolling or admin tasks.

  * Probably other forms of conversation!

WHAT'S EVEN MORE IMPORTANT, THOUGH:

We have no comprehensive code of conduct/mechanisms to combat harassment,
vandalism, and abuse.  Harassment or vandalism which is stopped in one
communication mechanism can be transferred to another with impunity.  IRC
in particular is seen as a space where (a) private discussions can happen
(good), but (b) there are no cops or consequences.

This is not really just a question of installing .
This is a challenge to the community to do the hard work of figuring out
our social contracts and what sort of conversations we want to support and
enable, which sorts of abuse we want to control, and what sorts of filters
to give users.

We can easily go too far -- I recommend reading
http://www.nytimes.com/2016/11/05/opinion/what-were-missing-while-we-obsess-over-john-podestas-email.html
for context.  A global panopticon [1] where no one can hold private
conversation is equally 

Re: [Wikimedia-l] [Wikitech-l] Update on WMF account compromises

[C. Scott Ananian]

On Wed, Nov 16, 2016 at 1:19 PM, Pine W  wrote:

> (1) If you find it difficult to remember strong passwords then consider
> using a password manager .
>

For Unix/GPG types, I can recommend http://www.passwordstore.org/ --
`aptitude install pass`.

It's very old-school cool.
  --scott

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Open letter to the new CTO

[C. Scott Ananian]

On Sun, Nov 13, 2016 at 5:08 PM, Rogol Domedonfors 
wrote:

> I have
> explicitly asked where plans for the future of the editors and the parsr
> unification project can be seen, and there has simply been no response.  Do
> those plans exist?  If so, where are they, and why are they not being
> shared wth the community.  If not, why and how is any work proceeding, and
> what process will be used to developt those plans, and in particular, hwow
> will the community be involved?  These are not questions of idle curiosity
> for one particular user's satisfaction, they issues requiring clear and
> public articuation as key components of any successful future staraegy to
> avoid the disastrous mistakes of the past.
>

In the past two years:

https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Handling_wiki_content_beyond_plaintext
(coming up!)
https://www.mediawiki.org/wiki/Parsing
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy/FAQ
https://wikimania2015.wikimedia.org/wiki/Submissions/Templates_are_dead!_Long_live_templates
!
https://wikimania2015.wikimedia.org/wiki/Submissions/Mediawiki_without_wikitext
https://wikimania2015.wikimedia.org/wiki/Submissions/Wikitext_is_broken,_long_live_wikitext_(2.0)

Fifthly I note that there have been repeated assurances over time that the
> content of the databases will continue to be wikitext, and that wikitext
> will be directly editable, at least for the foreseeable future.  Those
> assurances came from people who oight to know and who appeared to be
> speaking on behalf of, and with the authority of the WMF.  The comments
> made by Scott do not entirely support those assurances.
>

The "assurances" are not as black-and-white as you seem to think.  There
are a number of ways to translate on-the-fly between alternative
representations and wikitext, as well as some debate about what "wikitext"
actually is.  If we clean up a seldom-used corner case in the wikitext
specification, is that still "wikitext"?  If we replace wikitext templates
with Scribunto templates is it still "wikitext"?  If we change boldface to
{'' ... ''} instead of triple-quotes, is that still wikitext?  Etc.
Further, see:

https://www.mediawiki.org/wiki/Multi-Content_Revisions

for broader context on the backend changes, which will make it possible to
store multiple equivalent representations of any of our content ("legacy
wikitext", "wikitext 2.0", "HTML", etc), and translate on-the-fly
back-and-forth between them.  We currently do this for Flow, for example,
where the "in database" representation is HTML, even if you are editing it
in "wikitext".  So there are lots of ways to tweak the dials to always
allow "wikitext editing" -- which, indeed, is under no attack.  (Our
archives, however, are currently in quite a perilous state due to the
currently-underspecified nature of "wikitext".)

Multi-Content Revisions has been through a public RFC process:
https://phabricator.wikimedia.org/T107595

Indeed, the short answer to your question about process would be,
"Wikimania", "Developer Summit", and "Architecture Committee" (
https://www.mediawiki.org/wiki/Architecture_committee).  It is rare that
any substantial project at WMF hasn't been through all three of those
public forums, and records of each are posted for the benefit of those who
can't attend.  (Although this year at Esino Lario the public process
determined that the Wikimania attendees didn't actually want to have
parsing- or wikitext-related technical discussions, and so instead I
participated in a public hackathon for offline functionality organized by
the Kiwix community.  I surveyed attendees however and everyone I talked to
indicated that WMF staff was adequately represented and no one reported any
trouble finding staff members to answer questions.)
 --scott, [[User:cscott]]

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Open letter to the new CTO

[C. Scott Ananian]

I'm going to take the bait and respond in part, to defend the teams and
projects I work with:

On Tue, Nov 8, 2016 at 2:47 PM, Rogol Domedonfors 
wrote:

> they are summarised by the four words
>  *under-ambitious,
> under-resourced, under-managed and under-performing*. The VE/Parsoid/Flow
> complex suffers from scope mismatch. As a vehicle for delivering a WYSIWYG
> editor and discussion board it is over-complex,


I'll stop here.  I think it is poorly understood in the community how
complex wikitext markup has been allowed to grow over the decades it has
been under development.  There *is no specification for wikitext*.  We have
informal guides which omit most of the interesting corner cases, like, say,
priority between conflicting markup.  Take a look at
http://spec.commonmark.org/ to see what a precise specification for a *much
simpler* markup language would look like.  As you read through the cases in
that spec, consider that if you translated most of the examples into
wikitext, *literally no one knows what the expected output would be*.  The
implementation is too organic, with bits glommed on ad-hoc, and we'd
probably have to run them through the parser to find out what happens:
there is no way for a human to reason about it.

So, yes: VE/Parsoid are very complex (I'll leave Flow for a little further
down, be patient).  Part of this was a learning process: when I joined the
project in 2013 there was a perhaps-naïve sense that we could easily
implement a sort of "cleaned up wikitext" and migrate any markup that
broke.  Over the intervening years (and in response to heated criticism of
Visual Editor when the "cleaned up wikitext" failed to exactly match
editors' expectations), Parsoid has grown and grown, until it has almost as
many barnacles as the core PHP parser.

This is not only a challenge for engineering.  This is a challenge to the
community.  In order to actually achieve simplicity in our parser and
editor we will need to make aggressive changes to our content markup in
order to reverse years (decades) of poorly-understood workarounds to buggy
or underspecified wikitext syntax.  Yes, you can fault WMF management (and
I'll personally take some blame) for not aggressively pushing the community
into this action, but the community in its turn has been strongly resistant
to proposed changes in wikitext, which they characterize as "for the sake
of Visual Editor", not fully realizing the extent to which the obscurity of
the current wikitext syntax imperils the editability, archivability and
future usability of the content we are creating.

We need to tackle this challenge together.  Only when we commit to
aggressively updating the wikitext used in our projects, will we be able to
drop the "unnecessary" complexity of the parser-editor implementation.
There are a number of different proposals for "wikitext 2.0", more than one
of which I expect will be the subject of sessions at the developer summit
this year (
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Handling_wiki_content_beyond_plaintext).
But again: the engineers can't do it alone.  It's not just an engineering
problem.  We *started* with the engineering solution (simple parsoid/VE
with no compatibility barnacles) and had to spend the next three years in
further development because of social/human factors --- namely, every time
that VE or Parsoid "broke" something the solution was to complicate the
parser and editor, not to fix the wikitext.  If we want to scale down
ongoing development, we need to tackle the community side of the larger
issue of wikitext maintenance and migration.

I think you actually agree: you finish your open letter with, "Your staff
need to engage with users as equals, not de haut en bas. The community is
here to work with you if you will let it."  But this goes both ways -- as a
community we need to stop treating our existing content as sacrosanct, and
recognize that the community needs to accept change if they want
engineering to finish projects and move the platform forward.


> while VE and Flow are
> under-ambitious. Can these really be regarded as cutting edge in 2016?


Agreed.  We have collaborative features being rolled out in VE now, but
that just brings us to the state of the art circa 2005/6, when Google Docs
(nee Writely) was written (or ~2009, when AbiWord gained its collaborative
features in version 2.8.0).  Yes, we're late.  But the actual
implementation of a collaborative editor has always been the "easy part"
(see https://www.mediawiki.org/wiki/Extension:TogetherJS for example).  The
hard parts were:

1. Always generating exactly the wikitext a human editor would generate for
a given edit (which varies by projects).

2. Open social collaboration among tens of millions of users on WMF
projects (~30 million on enwiki alone), while respecting privacy and
preventing harassment.

I discussed #1 above.  #2 is still an open problem -- not just for us, but
for the "state 

Re: [Wikimedia-l] [Wmfall] Wikimedia Foundation executive transition update

[C. Scott Ananian]

On Thu, Mar 10, 2016 at 9:59 PM, Katherine Maher 
wrote:

> We are committed to delivering the first version of the 2016-2017 Annual
> Plan no later than April 1st for community and FDC review
>

It might be best if you can manage to deliver it on March 30th. ;)  The
next day tends to be a bit foolish.

At any rate: Congratulations!  Let's hope this is the start of the
good-news potion of 2016.
 --scott
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Why take grants?

[C. Scott Ananian]

On Wed, Feb 3, 2016 at 11:00 AM, Tim Landscheidt 
wrote:

> So the diversification for the purpose of the advancement of
> knowledge should not lie in making WMF immortal, but ensur-
> ing that it survives WMF's death.
>

Perhaps it will seem counterintuitive to you, but your reasoning is exactly
why I feel that pursuing grants and non-banner sorts of funding is a good
idea for the foundation.  We should *encourage* mirrors and forks and
distributed storage and lots of other interesting ways of spreading our
bits around and putting new clothes and user experiences on them.

Being totally dependent on banner fundraising on a small number of
"official" web sites works contrary to all of that.  It encourages
centralization, and starves other approaches of resources.  "Good citizens"
don't make Wikipedia forks, because it would be taking money from the WMF
by interfering with the banner campaigns.  That's a perverse incentive.
  --scott

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Why take grants? (was: Can we see the Knight grant application and grant offer?)

[C. Scott Ananian]

On Sat, Jan 30, 2016 at 11:43 AM, MZMcBride  wrote:

> One part of this arrangement still confuses me. In the linked post, you
> write, "With this grant we brought the idea to the funder and they
> supported our work with this grant."
>
> Why ask for and take the money? The Wikimedia Foundation can raise
> $250,000 in a few days (maybe hours) by placing ads on a few large
> Wikipedias soliciting donations. Why take on a restricted grant, with its
> necessary reporting overhead and other administrative costs?


Responding just to this small portion of MZMcBride's email:

When I interviewed at the WMF, back in Sue's tenure, I asked pointed
questions about the funding model since I was coming from a non-profit
which perennially struggled with funding.

Sue explained to me that the goal was to have WMF's budget be roughly 50%
grants and 50% user contributions to guard against unexpected fragility
with either of these funding sources.  There is/was the continuing concern
that folks accessing wikimedia content through non-traditional sources
(google snippets, mobile apps, etc) will not see or respond to a banner
campaign, so that sooner or later one of our banner campaigns will come up
very short.  Further, a reliance on banners for funding creates perverse
incentives that discourage us from fully embracing potential users of our
content who may bypass the "official" clients and their banner ads.

Similarly, from my time at OLPC I saw first hand that economic recession
can cause grant sources of funding to dry up seemingly overnight.  So to me
it seemed very wise not to put all the eggs in a single basket.  If grants
or banner campaigns came up short, the other side of the funding equation
could carry the load while the WMF retooled.

This was Sue's explanation.  I don't know if this is still the explicit
thinking of the current board/ED, but IMO it's still an entirely reasonable
rationale for pursuing grant funding, even if the grants come with more
"strings attached" than a banner campaign.
 --scott

ps. I'm deliberately not addressing the specifics of the Knight foundation
grant here, we can continue that discussion on the original thread.  I'm
just talking about grant funding in general.

-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Update from the Board

[C. Scott Ananian]

On Tue, Jan 26, 2016 at 4:21 PM, Dariusz Jemielniak 
wrote:

> hi Lodewijk,
> On Tue, Jan 26, 2016 at 3:28 PM, Lodewijk 
> wrote:
>
> > thanks for the update. It's been quite a while - and you don't seem to
> give
> > a clear time table for further updates.
>
> let me step in, since Alice is probably already asleep :) We're going to
> follow up with an update in a week or less.
>

I hope that you follow through with this plan, and give us a post-mortem in
a week's time.
 --scott
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Invitation to WMF November 2014 Metrics Activities Meeting: Thursday, December 4, 19:00 UTC

[C. Scott Ananian]

On Thu, Dec 4, 2014 at 7:18 PM, Asaf Bartov abar...@wikimedia.org wrote:
 On Thu, Dec 4, 2014 at 1:23 PM, C. Scott Ananian canan...@wikimedia.org
 wrote:
 1) Is the rise in global south page views specifically to *enwiki*, or
 is it to local wikis?
 Not actually an either/or.  The answer seems to me to be yes, i.e. all
 wikis -- that is, all projects, all languages.

It may *seem to you* to be yes, but the data indicates that the
answer differs, depending where you look.  For example, the data
clearly indicates that the stunning rise in Iran is almost entirely
due to enwiki.  enwiki gains over 80 million page views, fawiki gains
only 10 million.  See
https://en.wikipedia.org/wiki/User:Cscott/2014_December_metrics for a
convincing graph.

I think it's important that we determine the actual answers to these
questions, instead of trusting our instincts.

 Some definitely do.  Another major factor, mentioned today, is that in some
 countries, mobile devices just don't come with good local languages
 support, and people are putting up with that and using what the device does
 give them, which are generally the major, colonial languages.

Hm, the word colonial bothers me here.  I know you mean
historically colonial, but in the modern world English is also a
trade language, not just a formerly-colonial language.  Much access to
enwiki is due to its trade-language status.

I feel strongly that we have a moral obligation to offer good local
language support, but I also feel that we shouldn't label and dismiss
readers who want to learn/practice/find information in a trade
language. (This is one of the reasons I'm a fan of simplewiki, but
that's a whole 'nuther discussion.)

On Fri, Dec 5, 2014 at 2:05 AM, Salvador A salvador1...@gmail.com wrote:
 I was reading the presentation on metrics and the point about Mexico's
 decreasing of views on Wikipedia called my attention.

I dug into the numbers a little more; see the graphs at
https://en.wikipedia.org/wiki/User:Cscott/2014_December_metrics

It's a bit confusing.  At this moment I'm inclined to say that the
computation of decliners was in some way erroneous; neither the page
views for Mexico nor the overall pageviews for eswiki seem to support
the large annual declines reported.

On https://en.wikipedia.org/wiki/User:Cscott/2014_December_metrics I
compute an annual decline for Mexico of 12.4% (compared to 23.2%
reported at the metrics meeting), which compares to an eswiki annual
decline of 4.8% (excludings bots and spiders).

So Mexico is indeed concerning -- it's declining at three times the
eswiki rate.  But eswiki as a whole seems like it ought to also be a
concern.  And I'd like to understand why I can't reproduce the much
higher numbers shown in the Metrics meeting.
  --scott

-- 
(http://cscott.net)

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Invitation to WMF November 2014 Metrics Activities Meeting: Thursday, December 4, 19:00 UTC

[C. Scott Ananian]

Thanks everyone for a fantastic metrics meeting.

I had two questions which I raised on IRC which didn't get a chance to
be addressed.  Briefly:

1) Is the rise in global south page views specifically to *enwiki*, or
is it to local wikis?

2) Does the page view decrease in Latin America correspond to a
decline in the eswiki project specifically?  How do our numbers look
if we look at projects rather than countries?

Oliver shared one of the tools used to collate the graphs seen in the
meeting, and I was able to determine, for example, that the rise in
pageviews from Iran is almost entirely due to rises in Iranian access
to enwiki.  The growth in views of fawiki and other wikis from Iran is
much more modest.

It seems that our thinking about redirecting to localized content and
the rise of mobile in the global south should be informed by these
analytics.  Are folks coming to enwiki because that's where the
content and editors are?  If so we might be doing readers a disservice
by redirecting them to a local wiki without the content they are
seeking.  (Perhaps the Content Translation tool can help.)  If our
userbase in the global south is coming from mobile, than it is
important to provide localized editing tools for mobile; less so if
they are primarily English-speaking and can take advantage of the
desktop editors of enwiki.  Will investment in the Content Translation
tool affect the balance between enwiki and local wiki pageviews going
forward?

I dug into the numbers a little bit, others who are interested can
join me in a discussion over at
https://lists.wikimedia.org/mailman/listinfo/analytics

Thanks for your attention...
 --scott

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] [Offline-l] Bug day: Book tool/Collection/PDF, 2014-10-08, 14–22 UTC

[C. Scott Ananian]

Yes, thank you all so much!

I've been busy trying to fix as many of the issues found as possible.

Note that I'll be on vacation next week (2014-10-11 - 2014-10-17) so
don't panic if my latency increases.  Keep filing those bugs and I'll
keep squashing them when I get back.
  --scott

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] First _draft_ goals for WMF engineering/product

[C. Scott Ananian]

On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo)
nemow...@gmail.com wrote:
 My favourite toy to this purpose is Kiwix:
 * download a recent file for your favourite wiki at
 http://download.kiwix.org/zim/wikipedia/ ,
 * download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/ ,
 * start pressing random page and report surprises e.g. to
 https://sourceforge.net/p/kiwix/bugs/

I wrote http://nell-wikipedia.github.cscott.net a while ago with a
similar goal.  It is an offline wiki using parsoid output.  It needs a
bit of updating, since the Parsoid output has changed slightly since I
wrote it.

But you can also use http://parsoid.wmflabs.org/enwiki/Main_Page
directly now.  The Parsoid output includes a style sheet which ought
to render the parsoid DOM output identically to the standard PHP page
output.

We're constructing a visual diff tool this quarter so that soon we
should be able to do even better: testing for pixel-accurate matches
against standard output.  But that's not done yet, so bug reports on
Parsoid output and CSS/rendering issues are still valuable.
 --scott

-- 
(http://cscott.net)

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Rethink of observability

[C. Scott Ananian]

One small step forward might be to add more support to 'groups' in the
mediawiki codebase.  Groups could help organize the various subcommunities.
 Perhaps consider this a federal system for wikipedia. ;)

I have been experimenting with real-time collaborative editors on
wikipedia.  One question that arises is: how do I find others who are
interested in working on this particular page with me?  Currently there are
a number of ad-hoc methods used.

One could imagine that the participants on a particular article's talk page
consistute a sort of ad hoc group.  Various wikiprojects are a more
formal group.  But can we think about this more, and come up with better
mediawiki tools to find/discover/join/share/discuss things in our group(s)?
  --scott


On Thu, Jun 5, 2014 at 2:57 PM, Mingli Yuan mingli.y...@gmail.com wrote:

 Hi, Nemo,

 Can you please find that specific page/formulation of the principle?
  I'd like to reference it from point 1 of https://www.mediawiki.org/
  wiki/Principles but I couldn't find it with a quick search. (Note, it's
  not really *universally* accepted as a wiki principle.)
 

 It is at http://c2.com/cgi/wiki?WikiDesignPrinciples

 Hi, Samuel,

 Now we have so much metadata about pages and edits, we could cluster
  results in a more meaningful way...


 Yes! If Summly can help people read news, why not to observe wiki in a more
 meaningful way?

 https://en.wikipedia.org/wiki/Nick_D'Aloisio



 On Fri, Jun 6, 2014 at 2:31 AM, Federico Leva (Nemo) nemow...@gmail.com
 wrote:

  Mingli Yuan, 05/06/2014 19:43:
 
   If you visit the early page of c2.com, you will find the idea
  of observability is one pillar principle of wiki software, and just
 follow
  the idea, Ward invent the RecentChanges for all wikis.
 
 
  Can you please find that specific page/formulation of the principle?
  I'd like to reference it from point 1 of https://www.mediawiki.org/
  wiki/Principles but I couldn't find it with a quick search. (Note, it's
  not really *universally* accepted as a wiki principle.)
 
  Some rather big software development projects have failed, recently, in
  ways that a simple checklist like the page above could have avoided. So
  this is an important conversation to have.
 
 
 
  At that time c2 is very small; now Wikipedia is so big. The original
 idea
  of RecentChanges is not very effective today.
 
 
  Nor in 2002. :) http://c2.com/cgi/wiki?TooManyRecentChanges
 
 
   We had made some extension
  for the original idea in our mediawiki software, but I think the step is
  too small.
 
  Let's first take a look of what we had already invented are similar to
  RecentChanges but more effective:
 
  * Wikizine or Signpost: community stories every week
  * some part of a Portal: recent changes under a subject compiled by
 human
 
  Still possible for other kind of RecentChanges which is not invented
 yet,
  for example:
  * References and external links are very valuable resources, why not
  extract them from articles and compile them into a timeline?
 
 
  None of these escapes http://c2.com/cgi/wiki?RecentChangesIsNotTheWiki ;
  some have failed before:
 http://meatballwiki.org/wiki/RoleOfRecentChanges
 
 
 
  Content is only one aspect to observe, people are another:
 
 
  Attention, we're radically rooted in http://meatballwiki.org/wiki/
  ContentOverCommunity
 
 
   * Who are the experts on some topics?
  * Who are my buddies on some articles?
  * Who did help me to improve an article originally I wrote?
 
  In all, we may reshape our technical infrastructure in this direction
 for
  new spaces of participation. And finally, one open question for the
 system
  designer:
 
  * Towards better content and community, what is the most important
 things
  we want our user to observe?
 
 
  I'm not sure that's the right question. Anyway, more reading:
  http://meatballwiki.org/wiki/back=CategoryRecentChanges
  http://c2.com/cgi/wiki?search=RecentChanges
 
  Nemo
 
 
  ___
  Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
  wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe




-- 
(http://cscott.net)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] [Wikimedia Announcements] [PRESS RELEASE] Airtel Offers Nigerians Free Access to Wikipedia

[C. Scott Ananian]

This is a fascinating discussion, but one which has been addressed in
much greater depth elsewhere:
  http://lmgtfy.com/?q=net+neutrality+wikipedia+zero

It would indeed be interesting to hear EFF's take on the matter, which
does not appear to have been stated publicly yet.

Some related links:
http://theumlaut.com/2014/04/30/how-net-neutrality-hurts-the-poor/
see especially the first comment, which claims that You[r] concept of
net neutrality is technically, and wildly incorrect. [...] Net
neutrality has *nothing whatsoever* to do with access. Especially
access for poor users. It has to do with service providers being
treated equally and fairly on the *infrastructure* that allows users
access to those services.  (I don't know if I actually agree with
this, but it's an interesting distinction.)

http://manypossibilities.net/2014/05/net-neutrality-in-africa/

And the discussion starting here:
http://lists.wikimedia.org/pipermail/advocacy_advisors/2014-April/000472.html

One distinction which has been made in discussions concerns who is
paying for what, and who is profiting.  Zero-rating a commercial
service which pays the telecom for the privilege, might be regulated
differently than zero-rating a non-profit service with no money
changing hands.  (Does WP Zero actually pay any telecom to be
zero-rated?)
  --scott

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikimedia-l] Child Protection and Harassment Policy

[C. Scott Ananian]

You might be interested in look at projects like
http://schools-wikipedia.org/ and other subset wikis.  When I worked
at One Laptop per Child we distributed a offline Wikipedia slice along
with the XO-1 laptops to many schools and children.  We were in fact
careful to curate our offline article/image slice to avoid
gratuitously inappropriate content.  We felt this to be an appropriate
thing for OLPC to do, for its audience, *not* something we expected
upstream Wikipedia to do.  There are many differences between a
Children's Encyclopedia and Britannica!  OLPC did not censor links
in any way, so a laptop connected to the internet could see and follow
links to any article/image on Wikipedia (not just articles/images in
our curated offline subset).  Often schools deployed their own
content-filtering firewalls on their network connections.  We felt
this was a matter best implemented and managed by the school, with
their own local community standards.

Erik and I were spitballing wiki ideas last week, and one of the
things we discussed was ways to make it easier for third parties to
curate wikipedia subsets, as OLPC and the schools project did.  It is
certainly already possible, but it could be made easier.   If you are
interested in making a child friendly wikipedia, that is certainly
one way to go at it, and the ground is well trod.
  --scott

-- 
(http://cscott.net)

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Blocking Wil from this List

[C. Scott Ananian]

It seems to me that the community is going out of its way to accomodate Wil
in the hope that we can salvage the life partner of our new ED as a
productive contributor.
  --scott
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe