Re: [Wikitech-l] Fwd: Your speaking schedule at FOSDEM

[Sam Smith]

Awesome! Looking forward to tuning in.

-Sam

On Sun, Jan 17, 2016 at 8:37 PM, Jon Robson  wrote:

> Good luck Matt! Glad to hear you'll be the sharing your experience of
> conversions with the wider FOSS community.
>
> I look forward to seeing the streamed version!
> On 15 Jan 2016 2:17 p.m., "Matthew Flaschen" 
> wrote:
>
> > I will be presenting at FOSDEM on the LiquidThreads to Flow conversion,
> at
> > 2016-01-30, 16:00 Belgium time:
> >
> >
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=FOSDEM+LiquidThreads+to+Flow+talk+by+Matt+Flaschen%2C+Livestreamed=20160130T15
> >
> > It will be live-streamed at
> > https://live.fosdem.org/watch.php?room=H.2215%20(Ferrer) (from what I
> can
> > tell in advance).
> >
> > Thanks,
> >
> > Matt Flaschen
> >
> >  Forwarded Message 
> > Subject: Your speaking schedule at FOSDEM
> > Date: Fri, 15 Jan 2016 22:13:33 +0100 (CET)
> > From: FOSDEM Programme Team 
> > Reply-To: speak...@fosdem.org
> > Organization: FOSDEM - https://fosdem.org/
> > To: Matt Flaschen 
> > CC: speak...@fosdem.org
> >
> > Dear speaker,
> >
> > Thank you for agreeing to speak at FOSDEM!
> >
> > Our programme is now complete:
> >   https://fosdem.org/2016/schedule/
> >
> > This is your schedule:
> >
> >
> >
> ..
> > | day| time | room| title  |
> >
> >
> ++--+-+--+
> > | 2016-01-30 | 16:00:00 | H.2215 (Ferrer) | Converting LiquidThreads to
> > Flow |
> >
> >
> '+--+-+--'
> >
> > .-.
> > | links   |
> > +-+
> > | https://fosdem.org/2016/schedule/event/flow |
> > '-'
> >
> > Please check these links carefully.  If you already created an account
> at:
> >   https://fosdem.org/submit
> > you can login and update the information if need be.
> >
> > In particular, please upload a photograph if you have not already done
> > so and enter or update your biography.
> >
> > Changes take a few minutes to reach the website - the time it was last
> > updated appears at the bottom of this page:
> >   https://fosdem.org/2016/schedule/events/
> >
> > If you find yourself unable to attend, please let your room's organiser
> > know this as soon as possible.
> >
> > FOSDEM intends to record and stream the entire conference live - that's
> > over 300 hours of content!  The recordings will be published under the
> > same licence as all FOSDEM content (CC-BY).  You are agreeing to this by
> > taking part in the event.
> >
> > Any slide decks you present should be uploaded by about half-an-hour
> > before the start of your talk so that people watching the live stream
> > can follow them locally if their video resolution leaves slide content
> > indistinct.  (Our system does not hold back publication, so if you don't
> > want people to see them too far in advance, don't upload them yet.)
> >
> > Projectors work at 1024x768 but expect slides (and any demonstrations)
> > to be scaled down to 720x576 for the video, so try to make them
> > readable at this lower resolution if you can.
> >
> > Please don't forget to bring a VGA adaptor if you hope to present from a
> > laptop that only has a different type of output connector!  We also
> > recommend bringing a spare copy of any slides on a USB stick.
> >
> > As usual, we aim to provide free high-quality wireless network
> > connectivity throughout the event.
> >
> > Best wishes,
> >
> > The FOSDEM Programme Team
> >
> >
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community Wishlist Survey: Top 10 wishes!

[Bill Morrisson]

Thanks a lot for your input, my doubts are clear now :)

On Mon, Jan 11, 2016 at 10:53 PM, Andre Klapper 
wrote:

> On Sat, 2016-01-09 at 12:13 -0800, Brian Wolff wrote:
> > On Saturday, January 9, 2016, Rob Lanphier wrote:
> > > As Danny said, this is a wonderful thing to point out, and his
> > > answer
> > > way more authoritative than mine.  Thinking back to my early MediaWiki
> > > contribution experience, I would have loved to have had a ranked list
> > > of "these are things that are really important" so that I knew my
> > > contribution would ultimately be appreciated and important to the
> > > project.
> > >
> >
> > RIP bugzilla votes...
>
> I consider votes within a separate developer-focused tool (Bugzilla,
> which required a separate account) less representative than on-wiki.
> The latter allows a broader variety of community members to participate
> and raise their voices in an environment they are familiar with.
>
> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community Wishlist Survey: Top 10 wishes!

[Bill Morrisson]

@Rob Lanphier I was asking on behalf of myself

On Mon, Jan 18, 2016 at 12:41 PM, Bill Morrisson 
wrote:

> Thanks a lot for your input, my doubts are clear now :)
>
> On Mon, Jan 11, 2016 at 10:53 PM, Andre Klapper 
> wrote:
>
>> On Sat, 2016-01-09 at 12:13 -0800, Brian Wolff wrote:
>> > On Saturday, January 9, 2016, Rob Lanphier wrote:
>> > > As Danny said, this is a wonderful thing to point out, and his
>> > > answer
>> > > way more authoritative than mine.  Thinking back to my early MediaWiki
>> > > contribution experience, I would have loved to have had a ranked list
>> > > of "these are things that are really important" so that I knew my
>> > > contribution would ultimately be appreciated and important to the
>> > > project.
>> > >
>> >
>> > RIP bugzilla votes...
>>
>> I consider votes within a separate developer-focused tool (Bugzilla,
>> which required a separate account) less representative than on-wiki.
>> The latter allows a broader variety of community members to participate
>> and raise their voices in an environment they are familiar with.
>>
>> 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
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Video: Loading Barack Obama on 2G from Spain on a Nexus 5

[Federico Leva (Nemo)]

I'm allergic to videos as replacement of data, but does your video 
substantially differ from what tests give us, e.g. 
http://www.webpagetest.org/video/view.php?id=160118_YK_HKT.1.0 ?


It's easy to test multiple speeds (some tests still pending): 
http://www.webpagetest.org/video/compare.php?tests=160118_AZ_JH3,160118_VB_JGH,160118_X6_HM1,160118_KC_HM0,160118_YK_HKT,160118_2W_HKD


Some of the tests show significant CPU usage after the "everything and a 
kitchen sink" ResourceLoader phase in which some stuff for 
CentralNotice, Gather etc. etc. is loaded.


Mainly, the issue is to pick representative connections. There is some 
official data, some of which based on actual tests by probes, although 
it's limited:
* 
https://ec.europa.eu/digital-agenda/en/news/quality-broadband-services-eu (no 
mobile)
* 
https://ec.europa.eu/digital-agenda/en/news/use-commercial-mobile-networks-and-equipment-mission-critical-high-speed-broadband 
(needs some parsing!)


Nemo

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

[Wikitech-l] Governance model for Wikimedia software development (e.g. MediaWiki)

[Rob Lanphier]

Hi folks,

Over the past few weeks (including WikiDev '16) we've had several
conversations the Wikimedia software development governance model.
For a lot of people, the most important aspect of this is MediaWiki.
More generally, though, the scope is about we deploy to Wikimedia
sites that we intend to maintain, enhance, and further leverage.

On Wednesday, January 20, we intend to continue this conversation, and
welcome your participation:


In particular, we plan to discuss the work that Gabriel Wicke started:

"WIP RFC: Improving and scaling our technical decision making process"

...which is mainly a pointer to:


I've quoted the current text as of this writing below, and you're
welcome to reply on list or on the talk page (though let's try to
ensure a summary of important comments gets captured on T123606).

Based on the conversations I've been part of (and Gabriel's initial
writeup), Rust's governance model seems to be the leading candidate to
iterate toward.  This doesn't necessarily mean making one big change
with a fanfare-laden launch, but let's discuss.

Wait until Wednesday's IRC session if you have to (22:00 UTC, 14:00
PST), but we'd love to hear your thoughts sooner.

Rob
p.s. Here's the link to the RFC


...and below is the plain text from [mw:Requests for comment/Governance].


Problem statement

[Goal: Describe the problem we are seeing with the current process,
and why it is important to solve them.]

Difficulty of making clear and accepted decisions on important and
broad topics.
Scaling the decision making process.
Stakeholder involvement & legitimacy.
Clarity and transparency of decision making process.

Prior art

[Goal: Give a brief summary and pointers to options we looked at.]

IETF process
Python PEP process
Rust
Debian
W3C

See also this prior etherpad discussion.
Strawman proposal

[Goal: Summarize key ideas that we consider worth adopting, and point
to prior art. Provide rationale by explaining how each addresses
specific issues.]
More structured RFC decision process

Based on the Rust decision making process.

Nominate a shepherd from a (sub)team to guide an RFC through the process.
Makes sure that stakeholders are informed.
Guides the discussion.
Once the discussion plateaus or stalls & in coordination with
the RFC author(s), announces and widely publicizes a "Final Comment
Period", which is one week.
At the end of the "Final Comment Period", the (sub)team decides
based on the points made in the RFC discussion, and justifies its
decision based on the overall project principles and priorities. If
any new facts or aspects are surfaced in this discussion, a new Final
Comment Period needs to be started before making a decision.

Scaling the decision making process with sub-teams

Based on Rust subteams.

The core team is responsible for creating sub-teams, with a member
of the core team as its team leader. Initial membership is determined
by the leader, later changes are by consensus within the team.
Each sub-team has a specific vision and problem set to work on,
and the team leader is responsible for keeping the team on topic.
Sub-teams are empowered to decide on RFCs within their scope. The
team leader is responsible for elevating RFCs with unclear or broader
scope to the core team.

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

Re: [Wikitech-l] Could someone relatively new to Python please QA the Accuracy review login framework?

[James Salsman]

>>> Have you looked at using OAuth for authentication?
>>
>> Yes; the modules in use support OAuth but we made a conscious decision to
>> support anonymity. Lack of anonymity can interfere with the operation of the
>> reviewer reputation database.
>
> I'd love to read the background discussion that led to that decision.

Here is the pertinent excerpt:

"I would prefer to have text presented to reviewers anonymously. While
we can and do make reputation decisions about particular users,
wikipedia editing is generally pseudonymous with little control over
identity and password security. There are already tools for addressing
user-oriented issues. All of the accuracy review contemplated in the
original assignment assumes that review is anonymous so that reviewers
can not be influenced by, e.g., commercial loyalties or bribery."

> Could you identify which part of MediaWiki's OAuth implementation has
> unacceptable problems regarding anonymity?

Let me think about that and respond later, please. Upgrading to do
that might be more configuration than re-coding.

> If you are setting high standards/promises in that regard, your
> alternative implementation of user authentication will need to be
> extremely carefully written (as will your entire codebase need very
> good security auditing).

Hence my request for people to have a look at it. The Python Flask
default login system is being used.

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

[Wikitech-l] Could someone relatively new to Python please QA the Accuracy review login framework?

[James Salsman]

> Have you looked at using OAuth for authentication?

Yes; the modules in use support OAuth but we made a conscious decision to
support anonymity. Lack of anonymity can interfere with the operation of
the reviewer reputation database.

On Tuesday, January 12, 2016, James Salsman  wrote:

> An Outreachy candidate for http://mediawiki.org/wiki/Accuracy_review who
> went ahead and started unpaid has been making good progress, and is about
> to land the central guts of the project on github. It's a new way to
> transition from creating to maintaining Wikipedia articles, with an
> emphasis on detecting outdated statistics, fighting bias including paid
> advocacy of all kinds, and proofreading WEP student work. It's been going
> slow, mostly because the original trial run architecture was too dependent
> on email.
>
> However, before she gets there, could one or two people who are maybe
> beginner or intermediate with Python but advanced with Mediawiki or PHP
> please test her user authentication and login framework?
>
> https://github.com/priyankamandikal/wikireview/
> 
>
> It's built for PythonAnywhere because it shouldn't run on Wikimedia
> servers, because of the safe harbor DMCA provisions precluding editorial
> control by web hosts. Please report any issues on github and note your
> results on the Phabricator task to prevent duplication of effort.
>
> Thanks in advance!
>
> Best regards,
> Jim Salsman
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Could someone relatively new to Python please QA the Accuracy review login framework?

[John Mark Vandenberg]

On Tue, Jan 19, 2016 at 4:22 PM, James Salsman  wrote:
>> Have you looked at using OAuth for authentication?
>
> Yes; the modules in use support OAuth but we made a conscious decision to
> support anonymity. Lack of anonymity can interfere with the operation of the
> reviewer reputation database.

I'd love to read the background discussion that led to that decision.

Could you identify which part of MediaWiki's OAuth implementation has
unacceptable problems regarding anonymity?

If you are setting high standards/promises in that regard, your
alternative implementation of user authentication will need to be
extremely carefully written (as will your entire codebase need very
good security auditing).

-- 
John Vandenberg

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