[Wikitech-l] Supporting offline reading on the web - looking for testers

[Anne Gomez]

Hello!

The Reading team at the Wikimedia Foundation is working to support readers
who want to take articles offline to read and share later on their phones -
a use case we learned about from deep research earlier this year
 [0]. We’ve built a
few prototypes and are looking for people to test them, particularly people
who don’t know Wikipedia all that well.

We’d love if you could help us find anyone who doesn’t edit who might be
interested in this feature and would want to test it. If you know anyone
like this, please send them the following message:


Hello! Wikipedia needs your help to improve. We’re looking for people who
have internet access at least sometimes and like to have access to content
when they’re not connected to the internet. We would like to learn from
you. If you would be willing to participate in a study to tell us more,
please fill out this survey
 [1] before
November 25. Testing will only be available in English for now.

Thank you!

[1] https://wikimedia.qualtrics.com/SE/?SID=SV_09wJQzQs54DETUF This survey
is hosted on a third-party service. For information about data handling and
privacy, please see the survey privacy statement: https://wikimediafo
undation.org/wiki/Screener_Survey_for_Offline_Reading_
Study_Privacy_Statement


You can see the prototypes and leave comments on meta
[2], though please
don’t send this page to anyone filling out the survey as it could bias test
results.

Thanks,
Anne + New Readers

[0] https://meta.wikimedia.org/wiki/New_Readers/Findings
[1] (duplicated from excerpt above) https://wikimedia.qualt
rics.com/SE/?SID=SV_09wJQzQs54DETUF This survey is hosted on a third-party
service. For information about data handling and privacy, please see the
survey privacy statement: https://wikimediafoundation.org/wiki/Screener_
Survey_for_Offline_Reading_Study_Privacy_Statement
[2] https://meta.wikimedia.org/wiki/New_Readers/Offline
[3] https://meta.wikimedia.org/wiki/New_Readers/Target_countries

-- 
*Anne Gomez* // Reading Product Manager, New Readers

https://wikimediafoundation.org/


*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Donate
. *
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Awesome AI topics in need of discussion (Dev Summit)

[Aaron Halfaker]

Hey folks,

I'm your friendly facilitator for who forgot that today was the last day to
gather discussion on a set of topics of the Dev Summit.  I might be a bit
biased, but I think they are all pretty interesting, so I'm reaching out
with a quick overview to see if I can spur some interest from ya'll.  Check
'em out:


   - https://phabricator.wikimedia.org/T149373 -- Evaluating the user
   experience of AI systems
   - https://phabricator.wikimedia.org/T147710 -- Building an AI wishlist &
   working groups for Wikimedia Projects
   - https://phabricator.wikimedia.org/T148690 -- Where to surface AI in
   Wikimedia Projects
   - https://phabricator.wikimedia.org/T147929 -- Algorithmic dangers and
   transparency -- Best practices
   - https://phabricator.wikimedia.org/T149666 -- Next steps for machine
   translation

If you're interested, please drop a note or a token in the task.  BTW, you
don't have to physically attend the dev summit in order to participate.
I'll make sure that IRC and Etherpad are shared with all remote attendees
who want to attend the sessions I'm helping to organize.  I've heard that
there will be additional facilities for remote attendees (maybe a youtube
stream!?) this year, but I can't confirm yet.

-Aaron
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-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: [Wikitech-l] About the frontend development tools we use

[Željko Filipin]

On Fri, Nov 18, 2016 at 11:16 AM, Niklas Laxström  wrote:

> * Testing framework: We mostly use qUnit, Cucumber, Selenium. Of these
> only Cucumber appears in the top 6 and it has very low satisfaction
> (people who have used do not like it).
>

Direct link, for context:

http://stateofjs.com/2016/testing/

I would like to clarify. As far as I know, we use qunit for unit testing
frontend javascript code. We use cucumber for end-to-end/acceptance tests,
but only in combination with ruby, not javascript.

qunit and selenium are testing frameworks (generally speaking, a tool that
has setup, teardown, reporting...) and selenium is a browser driver,
something completely different. They are testing tools, and generally used
together, but not the same thing.

Some good news, we are experimenting with nodejs+mocha+selenium:

https://www.mediawiki.org/wiki/Selenium/Node.js

Watch that page, I am working on it, more good stuff is coming soon.

For me one pain point is automated testing of JavaScript code. It
> seems that testing frameworks, development practices and the way code
> is written could all be improved to make automated testing easier.
> Would there be interest in sharing comments how you do this and does
> what you do work well for you?
>

Are you interested in unit or end-to-end/acceptance testing? Both?
Something else?

Željko
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] About the frontend development tools we use

[Niklas Laxström]

I was reading http://stateofjs.com/2016/introduction/#sections and
could not avoid noticing that the frameworks or technologies we use
are not among the most popular or most liked among the participants of
this survey.

Examples:
* Frontend frameworks: We use jQuery and OOjs UI. The latter does not
appear at all in the list, jQuery is not in the top ten. This question
might be biased though on what people perceive as a framework.

* Testing framework: We mostly use qUnit, Cucumber, Selenium. Of these
only Cucumber appears in the top 6 and it has very low satisfaction
(people who have used do not like it).

* CSS tools: We use plain CSS and Less. Less has considerable lower
satisfaction than SASS/SCSS and is less popular.

* Build tools: We don't use these in core to my knowledge, but many
extensions seem to use Grunt for running linting tools. Again, Grunt
has very low satisfaction compared to other tools.

It is natural, that as large and complex project we do not jump to the
latest cool thing. I am not advocating to change tools that work well
for us, but I don't remember seeing a public discussion whether they
work well or not. Though, I am seeing some changes, for example
jscs+jshint being replaced with eslint.

We could possibly go faster or write better software with better tools
(of course this would need a careful evaluation). And while doing that
we could perhaps lower the barrier for new developers by using
something they already know. The topic of how to attract new
developers to our movement has been popular lately (for example [1]).

[1] https://phabricator.wikimedia.org/T148911



For me one pain point is automated testing of JavaScript code. It
seems that testing frameworks, development practices and the way code
is written could all be improved to make automated testing easier.
Would there be interest in sharing comments how you do this and does
what you do work well for you?

  -Niklas

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l