Re: [Wikitech-l] Improving static analysis tools for MediaWiki.

[Andre Klapper]

Hi Krys,

On Mon, 2015-03-09 at 17:23 -0800, Krys Nu wrote:
> I wish to express my interest in working on the above mentioned project. I
> have the required technical skill -PHP- and I am willing tread new grounds.
> I would love to discuss more about the project, what is really expected of
> the student, to establish some measurable goals before getting myself soak
> into the community.

"Improving static analysis tools for MW" sounds like a wide topic.
Could you provide more context please? Is this about some proposed
Google Summer of Code / Outreachy task? Is there a link to some wiki
page or Phabricator task providing more details?

You might not get much feedback on a mailing list if you only write
"Please discuss with me" without providing a proposal or question. :)

Cheers,
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

Re: [Wikitech-l] MediaWiki tests will verify the completeness of $wgAvailableRights

[hoo]

This has been merged now.


On Sat, 2015-02-21 at 18:27 +0100, hoo wrote:
> Hi Everyone,
> 
> just wanted to quickly let you know that MediaWiki will verify that
> extensions register all rights they define in $wgAvailableRights (or
> using the "UserGetAllRights" hook).
> 
> To make sure your extension complies with that just add all the rights
> your extension defines to $wgAvailableRights (which is a simple string[]
> of theses user rights).
> 
> This test will be introduced with https://gerrit.wikimedia.org/r/192087
> 
> Cheers,
> 
> Marius
> 
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Derric Atzrott]

I think pretty much anything is better than the current situation.  I'd
support this proposal.

The timing is right too with the WMF vs NSA lawsuit just happening.

On Mon, Mar 16, 2015 at 1:29 AM, Arlo Breault 
wrote:

> I share Risker’s concerns here and limiting the anonymity
> set to the intersection of Tor users and established wiki
> contributors seems problematic. Also, the bootstrapping
> issue needs working out and relegating Tor users to second
> class citizens that need to edit through a proxy seems less
> than ideal (though the specifics of that are unclear to me).
>
> But, at a minimum, this seems like a useful exercise to
> run if only for the experimental results and to show good faith.
>
> I’m more than willing to help out. Please get in touch.
>
> Arlo
>
>
>
>
> On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote:
>
> > On Mar 11, 2015 2:23 AM, "Gergo Tisza"  gti...@wikimedia.org)> wrote:
> > >
> > > On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp  (mailto:cste...@wikimedia.org)>
> > wrote:
> > >
> > > > I'm actually envisioning that the user would edit through the third
> > party's
> > > > proxy (via OAuth, linked to the new, "Special Account"), so no
> special
> > > > permissions are needed by the "Special Account", and a standard
> block on
> > > > that username can prevent them from editing. Additionally, revoking
> the
> > > > OAuth token of the proxy itself would stop all editing by this
> process,
> > >
> >
> >
> > so
> > > > there's a quick way to "pull the plug" if it looks like the edits are
> > > > predominantly unproductive.
> > >
> > >
> > >
> > > I'm probably missing the point here but how is this better than a plain
> > > edit proxy, available as a Tor hidden service, which a 3rd party can
> set
> >
> >
> > up
> > > at any time without the need to coordinate with us (apart from getting
> an
> > > OAuth key)? Since the user connects to them via Tor, they would not
> learn
> > > any private information; they could be authorized to edit via normal
> OAuth
> > > web flow (that is not blocked from a Tor IP); the edit would seemingly
> >
> >
> > come
> > > from the IP address of the proxy so it would not be subject to Tor
> >
> >
> > blocking.
> >
> >
> >
> > Setting up a proxy like this is definitely an option I've considered. As
> I
> > did, I couldn't think of a good way to limit the types of accounts that
> > used it, or come up with an acceptable collateral I could keep from the
> > user, that would prevent enough spammers to keep it from being blocked
> > while being open to people who needed it. The blinded token approach lets
> > the proxy rely on a trusted assertion about the identity, by the people
> who
> > it will impact if they get it wrong. That seemed like a good thing to me.
> >
> > However, we could substitute the entire blinding process with a public
> page
> > that the proxy posts to that says, "this user wants to use tor to edit,
> > vote yes or no and we'll allow them based on your opinion". And the proxy
> > only allows tor editing by users with a passing vote.
> >
> > That might be more palatable for enwiki's socking policy, with the risk
> > that if the user's IP has ever been revealed before (even if they went
> > through the effort of getting it deleted), there is still data to link
> them
> > to their real identity. The blinding breaks that correlation. But maybe a
> > more likely first step to actually getting tor edits?
> >
> > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Gergo Tisza]

On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp  wrote:

> Setting up a proxy like this is definitely an option I've considered. As I
> did, I couldn't think of a good way to limit the types of accounts that
> used it, or come up with an acceptable collateral I could keep from the
> user, that would prevent enough spammers to keep it from being blocked
> while being open to people who needed it.


Well, the obvious collateral is always money; and with bitcoin going
mainstream, untraceable money transfers are now accessible even to
nontechnical users (although I don't know Not sure if the mere act of
buying bitcoins could endanger someone in certain oppressive regimes).
Something like $10 is probably not a serious hurdle to anyone intent on
avoiding censorship but enough to deter spammers. The money could be
donated to the Tor project, or retained and returned after a certain number
of edits.

To make blocks more granular, some identifier such as the bitcount
transaction ID could be exposed via XFF so administrators would still be
able to assign blocks based on collaterals. That seems to me like a
significantly easier setup than using the reputation of an existing user as
collateral - that becomes really difficult if you want to both keep the
association hidden and punish users who vouch for spammers.

Maybe the proxy is not even necessary (it would certainly bring a host of
usability issues) and all that's needed is a gateway to buy editblocked
rights for users.

The blinded token approach lets
> the proxy rely on a trusted assertion about the identity, by the people who
> it will impact if they get it wrong. That seemed like a good thing to me.


I don't think it's the most practical solution for this specific use case,
but if it could be generalized, the ability to create a limited number of
tokens per user which are anonymous but assert that the creator passed some
condition (e.g. >1000 edits) and can be used up in some way would be
exciting as it would allow proper voting systems. No idea if that can be
fit into the OAuth framework, though (or if it's even possible without
having two independent authorities both of which have only partial access
to the data).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Daniel Friesen]

On 2015-03-16 2:30 PM, Gergo Tisza wrote:
> On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp  wrote:
>
>> Setting up a proxy like this is definitely an option I've considered. As I
>> did, I couldn't think of a good way to limit the types of accounts that
>> used it, or come up with an acceptable collateral I could keep from the
>> user, that would prevent enough spammers to keep it from being blocked
>> while being open to people who needed it.
>
> Well, the obvious collateral is always money; and with bitcoin going
> mainstream, untraceable money transfers are now accessible even to
> nontechnical users (although I don't know Not sure if the mere act of
> buying bitcoins could endanger someone in certain oppressive regimes).
> Something like $10 is probably not a serious hurdle to anyone intent on
> avoiding censorship but enough to deter spammers. The money could be
> donated to the Tor project, or retained and returned after a certain number
> of edits.
Bitcoin is not untraceable.

An adversary capable enough to eavesdrop on dissidents' communication
making them need Tor should be capable of tracing the publicly available
bitcoin transaction logs back from the payment to the proxy owner to the
originating non-anonymous financial transaction used to purchase the
bitcoins.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Max Semenik]

On Mon, Mar 16, 2015 at 2:30 PM, Gergo Tisza  wrote:

> Well, the obvious collateral is always money; and with bitcoin going
> mainstream, untraceable money transfers are now accessible even to
> nontechnical users (although I don't know Not sure if the mere act of
> buying bitcoins could endanger someone in certain oppressive regimes).
> Something like $10 is probably not a serious hurdle to anyone intent on
> avoiding censorship but enough to deter spammers. The money could be
> donated to the Tor project, or retained and returned after a certain number
> of edits.
>

In some jurisdictions Bitcoin is outright prohibited, with penalties for
end users for mere ownership of any amounts. Would be very funny to require
people to expose their asses to more problems in order to edit Wikipedia.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Nick Wilson (Quiddity)]

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width & side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox


-- 
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation

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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Risker]

How about just converting those threads back to Wikitext, instead?  That
script already exists, I've seen it used on Mediawiki. Will it mess up the
pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered
barely suitable when it was first developed with "new" software that can't
even do what that old, long-neglected software could do...and in several
cases, there is no intention to ever add the features already available
using Wikitext.

As expectations increase for project users to post their
comments/concerns/ideas/observations on Mediawiki, the use of Flow will
become a barrier for participation.

Risker/Anne


On 16 March 2015 at 20:51, Nick Wilson (Quiddity) 
wrote:

> LiquidThreads (LQT) has not been well-supported in a long time. Flow
> is in active development, and more real-world use-cases will help
> focus attention on the higher-priority features that are needed. To
> that end, LQT pages at mediawiki.org will start being converted to
> Flow in the next couple of weeks.
>
> There are about 1,600 existing LQT pages on Mediawiki, and the three
> most active pages are VisualEditor/Feedback, Project:Support_desk, and
> Help_talk:CirrusSearch.[1] The Collaboration team has been running
> test conversions of those three pages, and fixing issues that have
> come up. Those fixes are almost complete, and the team will be ready
> to start converting LQT threads to Flow topics soon. (If you’re
> interested in the progress, check out phab:T90788[2] and linked
> tasks.) The latest set is visible at a labs test server.[3] See an
> example topic comparison here: Flow vs LQT.[4])
>
> The VisualEditor/Feedback page will be converted first (per James'
> request), around the middle of next week. We’ll pause to assess any
> high-priority changes required. After that, we will start converting
> more pages. This process may take a couple of weeks to fully run.
>
> The last page to be converted will be Project:Support_desk, as that is
> the largest and most active LQT Board.
>
> LQT Threads that are currently on your watchlist, will still be
> watchlisted as Flow Topics. New Topics created at Flow Boards on your
> watchlist will appear in your Echo notifications, and you can choose
> whether or not to watchlist them.
>
> The LQT namespaces will continue to exist. Links to posts/topics will
> redirect appropriately, and the LQT history will remain available at
> the original location, as well as being mirrored in the Flow history.
>
> There’s a queue of new features in Flow that will be shipped over the
> next month or so:
>
> * Table of Contents is done
> * Category support for Flow Header and Topics is done
> * VE with editing toolbar coming last week of March (phab:T90763) [5]
> * Editing other people’s comments coming last week of March (phab:T91086)
> * Ability to change the width & side rail in progress, probably out in
> April (phab:T88114])
> * Search is in progress (no ETA yet) (phab:T76823)
> * The ability to choose which Flow notifications end up in Echo,
> watchlist, or both, and other more powerful options, will be coming up
> next (no ETA yet)
>
> That being said -- there are some LiquidThreads features that don’t
> exist in Flow yet.
> We’d like to hear which features you use on the current LQT boards,
> and that you’re concerned about losing in the Flow conversion. At the
> same time, we’d like further suggestions on how we could improve upon
> that (or other) features from LQT.
>
> Please give us feedback at
> https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
> centralized, and test freely at the sandbox.[6]
>
> Much thanks, on behalf of the Collaboration Team,
> Quiddity (WMF)
>
> [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
> https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
> https://www.mediawiki.org/wiki/Project:Support_desk
> [2] https://phabricator.wikimedia.org/T90788
> [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
> http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
> [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
>
> https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
> [5] https://phabricator.wikimedia.org/T90763 ,
> https://phabricator.wikimedia.org/T91086 ,
> https://phabricator.wikimedia.org/T88114 ,
> https://phabricator.wikimedia.org/T76823
> [6] https://www.mediawiki.org/wiki/Talk:Sandbox
>
>
> --
> Nick Wilson (Quiddity)
> Community Liaison
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Jon Robson]

Fiayy!
So happy to hear this is happening :)
 On 16 Mar 2015 17:52, "Nick Wilson (Quiddity)" 
wrote:

> LiquidThreads (LQT) has not been well-supported in a long time. Flow
> is in active development, and more real-world use-cases will help
> focus attention on the higher-priority features that are needed. To
> that end, LQT pages at mediawiki.org will start being converted to
> Flow in the next couple of weeks.
>
> There are about 1,600 existing LQT pages on Mediawiki, and the three
> most active pages are VisualEditor/Feedback, Project:Support_desk, and
> Help_talk:CirrusSearch.[1] The Collaboration team has been running
> test conversions of those three pages, and fixing issues that have
> come up. Those fixes are almost complete, and the team will be ready
> to start converting LQT threads to Flow topics soon. (If you’re
> interested in the progress, check out phab:T90788[2] and linked
> tasks.) The latest set is visible at a labs test server.[3] See an
> example topic comparison here: Flow vs LQT.[4])
>
> The VisualEditor/Feedback page will be converted first (per James'
> request), around the middle of next week. We’ll pause to assess any
> high-priority changes required. After that, we will start converting
> more pages. This process may take a couple of weeks to fully run.
>
> The last page to be converted will be Project:Support_desk, as that is
> the largest and most active LQT Board.
>
> LQT Threads that are currently on your watchlist, will still be
> watchlisted as Flow Topics. New Topics created at Flow Boards on your
> watchlist will appear in your Echo notifications, and you can choose
> whether or not to watchlist them.
>
> The LQT namespaces will continue to exist. Links to posts/topics will
> redirect appropriately, and the LQT history will remain available at
> the original location, as well as being mirrored in the Flow history.
>
> There’s a queue of new features in Flow that will be shipped over the
> next month or so:
>
> * Table of Contents is done
> * Category support for Flow Header and Topics is done
> * VE with editing toolbar coming last week of March (phab:T90763) [5]
> * Editing other people’s comments coming last week of March (phab:T91086)
> * Ability to change the width & side rail in progress, probably out in
> April (phab:T88114])
> * Search is in progress (no ETA yet) (phab:T76823)
> * The ability to choose which Flow notifications end up in Echo,
> watchlist, or both, and other more powerful options, will be coming up
> next (no ETA yet)
>
> That being said -- there are some LiquidThreads features that don’t
> exist in Flow yet.
> We’d like to hear which features you use on the current LQT boards,
> and that you’re concerned about losing in the Flow conversion. At the
> same time, we’d like further suggestions on how we could improve upon
> that (or other) features from LQT.
>
> Please give us feedback at
> https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
> centralized, and test freely at the sandbox.[6]
>
> Much thanks, on behalf of the Collaboration Team,
> Quiddity (WMF)
>
> [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
> https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
> https://www.mediawiki.org/wiki/Project:Support_desk
> [2] https://phabricator.wikimedia.org/T90788
> [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
> http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
> [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
>
> https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
> [5] https://phabricator.wikimedia.org/T90763 ,
> https://phabricator.wikimedia.org/T91086 ,
> https://phabricator.wikimedia.org/T88114 ,
> https://phabricator.wikimedia.org/T76823
> [6] https://www.mediawiki.org/wiki/Talk:Sandbox
>
>
> --
> Nick Wilson (Quiddity)
> Community Liaison
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Ryan Lane]

On Mon, Mar 16, 2015 at 6:02 PM, Risker  wrote:

> How about just converting those threads back to Wikitext, instead?  That
> script already exists, I've seen it used on Mediawiki. Will it mess up the
> pages that have already been converted using that script?
>
> Bottom line, it makes no sense to replace software that was considered
> barely suitable when it was first developed with "new" software that can't
> even do what that old, long-neglected software could do...and in several
> cases, there is no intention to ever add the features already available
> using Wikitext.
>
> As expectations increase for project users to post their
> comments/concerns/ideas/observations on Mediawiki, the use of Flow will
> become a barrier for participation.
>
>
As someone who used LQT a lot, I'd say I'd much rather flow replace the
pages I maintained using LQT. Maybe you dislike flow, but it's *way* more
useful than wikitext for discussion. I never want to go back to the days
where I needed to discuss things with wikitext ever again. Wikitext
discussion pages are just the absolute worst.

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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Risker]

On 16 March 2015 at 21:20, Ryan Lane  wrote:

> On Mon, Mar 16, 2015 at 6:02 PM, Risker  wrote:
>
> > How about just converting those threads back to Wikitext, instead?  That
> > script already exists, I've seen it used on Mediawiki. Will it mess up
> the
> > pages that have already been converted using that script?
> >
> > Bottom line, it makes no sense to replace software that was considered
> > barely suitable when it was first developed with "new" software that
> can't
> > even do what that old, long-neglected software could do...and in several
> > cases, there is no intention to ever add the features already available
> > using Wikitext.
> >
> > As expectations increase for project users to post their
> > comments/concerns/ideas/observations on Mediawiki, the use of Flow will
> > become a barrier for participation.
> >
> >
> As someone who used LQT a lot, I'd say I'd much rather flow replace the
> pages I maintained using LQT. Maybe you dislike flow, but it's *way* more
> useful than wikitext for discussion. I never want to go back to the days
> where I needed to discuss things with wikitext ever again. Wikitext
> discussion pages are just the absolute worst.
>
>

I hear what you are saying, Ryan.  I'm also reflecting on the fact that as
there is increasing pressure on "ordinary" editors to post their
discussions about Mediawiki on the Mediawikiwiki, they would then
encountering *another* new interface that doesn't operate in anything
similar to what they've experienced before, and that we know isn't up to
handling stuff that even LQT handled without blinking.  On the other hand,
based on what I'm hearing about the "success" of  installing Flow on
Office-wiki, the end result may very well be fewer people coming to
complain about something else, which might be viewed as a net positive.

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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Risker]

At the end of the day, the key is communicating with communities to work
things out with them - and that may well have to happen on a
project-by-project basis.  Finding a mid-size project with a very active
admin corps that would be willing to try out whatever you folks come up
with is probably a place to start: if it goes well there, it will raise the
chances of acceptance elsewhere.  What needs to be demonstrated is that
permitting editing through Tor under (to be specified) controlled
conditions results in improvements to the targeted project without
increased vandalism and spamming - and yes, it's entirely reasonable to
expect that there will be active participation by those who are advocating
this change to monitor and evaluate the change.  Ensure that the processes
for evaluating edits through those accounts are set up before activating
the access, and have a pre-arranged set of conditions where the access
would be withdrawn.

Risker/Anne





On 16 March 2015 at 01:29, Arlo Breault  wrote:

> I share Risker’s concerns here and limiting the anonymity
> set to the intersection of Tor users and established wiki
> contributors seems problematic. Also, the bootstrapping
> issue needs working out and relegating Tor users to second
> class citizens that need to edit through a proxy seems less
> than ideal (though the specifics of that are unclear to me).
>
> But, at a minimum, this seems like a useful exercise to
> run if only for the experimental results and to show good faith.
>
> I’m more than willing to help out. Please get in touch.
>
> Arlo
>
>
>
>
> On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote:
>
> > On Mar 11, 2015 2:23 AM, "Gergo Tisza"  gti...@wikimedia.org)> wrote:
> > >
> > > On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp  (mailto:cste...@wikimedia.org)>
> > wrote:
> > >
> > > > I'm actually envisioning that the user would edit through the third
> > party's
> > > > proxy (via OAuth, linked to the new, "Special Account"), so no
> special
> > > > permissions are needed by the "Special Account", and a standard
> block on
> > > > that username can prevent them from editing. Additionally, revoking
> the
> > > > OAuth token of the proxy itself would stop all editing by this
> process,
> > >
> >
> >
> > so
> > > > there's a quick way to "pull the plug" if it looks like the edits are
> > > > predominantly unproductive.
> > >
> > >
> > >
> > > I'm probably missing the point here but how is this better than a plain
> > > edit proxy, available as a Tor hidden service, which a 3rd party can
> set
> >
> >
> > up
> > > at any time without the need to coordinate with us (apart from getting
> an
> > > OAuth key)? Since the user connects to them via Tor, they would not
> learn
> > > any private information; they could be authorized to edit via normal
> OAuth
> > > web flow (that is not blocked from a Tor IP); the edit would seemingly
> >
> >
> > come
> > > from the IP address of the proxy so it would not be subject to Tor
> >
> >
> > blocking.
> >
> >
> >
> > Setting up a proxy like this is definitely an option I've considered. As
> I
> > did, I couldn't think of a good way to limit the types of accounts that
> > used it, or come up with an acceptable collateral I could keep from the
> > user, that would prevent enough spammers to keep it from being blocked
> > while being open to people who needed it. The blinded token approach lets
> > the proxy rely on a trusted assertion about the identity, by the people
> who
> > it will impact if they get it wrong. That seemed like a good thing to me.
> >
> > However, we could substitute the entire blinding process with a public
> page
> > that the proxy posts to that says, "this user wants to use tor to edit,
> > vote yes or no and we'll allow them based on your opinion". And the proxy
> > only allows tor editing by users with a passing vote.
> >
> > That might be more palatable for enwiki's socking policy, with the risk
> > that if the user's IP has ever been revealed before (even if they went
> > through the effort of getting it deleted), there is still data to link
> them
> > to their real identity. The blinding breaks that correlation. But maybe a
> > more likely first step to actually getting tor edits?
> >
> > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Nick Wilson (Quiddity)]

On Mon, Mar 16, 2015 at 6:02 PM, Risker  wrote:
> How about just converting those threads back to Wikitext, instead?  That
> script already exists, I've seen it used on Mediawiki. Will it mess up the
> pages that have already been converted using that script?
>
> Bottom line, it makes no sense to replace software that was considered
> barely suitable when it was first developed with "new" software that can't
> even do what that old, long-neglected software could do...and in several
> cases, there is no intention to ever add the features already available
> using Wikitext.
>
> As expectations increase for project users to post their
> comments/concerns/ideas/observations on Mediawiki, the use of Flow will
> become a barrier for participation.
>
> Risker/Anne
>

Converting LQT to Wikitext would lose the major benefits of:
* per-Topic watchlisting,
* per-Topic category support,
* Sortable views (with Filterable views on the roadmap [1]),
as well as the immensely easier process for new-editors to be able to
participate in discussions, and be notified about replies.[2]

[1] See Pau's design notes at
https://docs.google.com/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK95pc0Whs/edit#slide=id.p
and Hhhippo's ideas/notes at
https://en.wikipedia.org/wiki/User:Hhhippo/Flow/TOC_and_filters
[2] The feedback from the ongoing trial at the Frwiki newcomers'
helpdesk, is that the Flow version has better engagement, with more
editors returning to give further information, or ask a followup
question, or just to say thanks.
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux/Flow
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux

Flow has been improving over the months. I hope you'll give it a try
at the sandbox, check out the list of upcoming features (in 1st
message), and let the
team know what feature(s) you're most concerned about. The more
specific the feedback, the more it will help influence the order new
features are developed in.

Thanks, as always :)
Quiddity (WMF)

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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Gergo Tisza]

On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen 
wrote:

> Bitcoin is not untraceable.
>
> An adversary capable enough to eavesdrop on dissidents' communication
> making them need Tor should be capable of tracing the publicly available
> bitcoin transaction logs back from the payment to the proxy owner to the
> originating non-anonymous financial transaction used to purchase the
> bitcoins.
>

I'll admit not knowing much about bitcoin security, but isn't that what
mixers are for?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Proposal for Outreachy program 2015

[Divya]

Hi All,

I am Dibya Singh and I am applying for FOSS Outreachy 10. I have selected a
project from #possible-tech-projects list named One stop translation to
improve consistency for translation. I have been in contact with mentor
Niklas Laxström and Federico Leva alias for understanding the project in
depth. I have drafted a rough proposal based on my interaction with the
product as a user.

Please find link for my proposal. Please give your valuable feedback.
https://phabricator.wikimedia.org/T92929

Link for my mediawiki user page can be found here


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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Daniel Friesen]

On 2015-03-16 7:55 PM, Gergo Tisza wrote:
> On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen 
> wrote:
>
>> Bitcoin is not untraceable.
>>
>> An adversary capable enough to eavesdrop on dissidents' communication
>> making them need Tor should be capable of tracing the publicly available
>> bitcoin transaction logs back from the payment to the proxy owner to the
>> originating non-anonymous financial transaction used to purchase the
>> bitcoins.
>>
> I'll admit not knowing much about bitcoin security, but isn't that what
> mixers are for?
Assuming those work, they make bitcoin even less accessible to the
nontechnical users and many of the users of the proxy would likely not
do so, endangering themselves.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Florian Schmidt]

I fully upport and welcome this, but at least for Project:Support_desk you 
should communicate this on this LQT board, too, that it will be converted (if 
you didn't do hat already, i haven't looked now, because LQT ist terrible on 
mobile :P). There are probably very active supporters, who haven't subscribed 
this list, but they should have the possibility to post their needs and 
opinions about that.

Best,
Florian

Gesendet mit meinem HTC

- Reply message -
Von: "Nick Wilson (Quiddity)" 
An: "Wikimedia developers" 
Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at 
mediawiki.org
Datum: Di., März 17, 2015 01:51

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width & side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox


-- 
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation

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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Kevin Wayne Williams]

Nick Wilson (Quiddity) schreef op 2015/03/16 om 17:51:

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.


I assume that the intention is to greater increase the divide between 
Wikipedia editors and the Wikimedia Foundation? It would be nice if the 
WMF would focus on becoming good with the tools that editors use instead 
of attempting to convince them that inadequate substitutes are adequate.


KWW


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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Kevin Wayne Williams]

Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03:

On Mon, Mar 16, 2015 at 6:02 PM, Risker  wrote:

How about just converting those threads back to Wikitext, instead?  That
script already exists, I've seen it used on Mediawiki. Will it mess up the
pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered
barely suitable when it was first developed with "new" software that can't
even do what that old, long-neglected software could do...and in several
cases, there is no intention to ever add the features already available
using Wikitext.

As expectations increase for project users to post their
comments/concerns/ideas/observations on Mediawiki, the use of Flow will
become a barrier for participation.

Risker/Anne



Converting LQT to Wikitext would lose the major benefits of:
* per-Topic watchlisting,
* per-Topic category support,
* Sortable views (with Filterable views on the roadmap [1]),
as well as the immensely easier process for new-editors to be able to
participate in discussions, and be notified about replies.[2]



But it would provide the advantage of using the standardized discussion 
technique used in virtually all Wikimedia installations. There doesn't 
seem to be any particular user demand to adopt Flow, so there's no 
reason to believe it will gain any more traction than LQT ever did.


KWW


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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Pine W]

Pardon me if I missed an announcement, but will there be any office hours
about Flow in the near future? I have a few general questions about
cross-wiki discussions and the relationship of Flow to VE. (I'm mostly
focused on VE right now.)

Thanks,
Pine
On Mar 16, 2015 11:21 PM, "Kevin Wayne Williams" 
wrote:

> Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03:
>
>> On Mon, Mar 16, 2015 at 6:02 PM, Risker  wrote:
>>
>>> How about just converting those threads back to Wikitext, instead?  That
>>> script already exists, I've seen it used on Mediawiki. Will it mess up
>>> the
>>> pages that have already been converted using that script?
>>>
>>> Bottom line, it makes no sense to replace software that was considered
>>> barely suitable when it was first developed with "new" software that
>>> can't
>>> even do what that old, long-neglected software could do...and in several
>>> cases, there is no intention to ever add the features already available
>>> using Wikitext.
>>>
>>> As expectations increase for project users to post their
>>> comments/concerns/ideas/observations on Mediawiki, the use of Flow will
>>> become a barrier for participation.
>>>
>>> Risker/Anne
>>>
>>>
>> Converting LQT to Wikitext would lose the major benefits of:
>> * per-Topic watchlisting,
>> * per-Topic category support,
>> * Sortable views (with Filterable views on the roadmap [1]),
>> as well as the immensely easier process for new-editors to be able to
>> participate in discussions, and be notified about replies.[2]
>>
>>
> But it would provide the advantage of using the standardized discussion
> technique used in virtually all Wikimedia installations. There doesn't seem
> to be any particular user demand to adopt Flow, so there's no reason to
> believe it will gain any more traction than LQT ever did.
>
> KWW
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l