[Wikimedia-l] [Wikitech-l] Reflecting on my listening tour

[Brian Wolff]

Perhaps i am hyperfocused on technical debt in the sense of improving the
abstractions used in mediawiki. The phrasing around sustainability
especially leads me in that direction. However, technical debt is certainly
a broad concept and can mean a lot of things.

The common thread in the examples you cited seem to be things that have
fallen through the ownership cracks. I'm not sure its the case that
engineers aren't incentivized to fix these, so much as there are no natural
engineers to be incentivized due to team structure (scribunto is an
exception but i would disagree with that task's inclusion for reasons that
get off topic). On the other hand, perhaps a different incentivization
structure would encourage people to branch out more.

I think it is especially telling that 3 (or 4 even) of these tasks are
multimedia related, given that wmf hasn't had a multimedia team in a very
long time [SDC does not count], and definitely not one focused on the
backend. There are quite a few multimedia related areas in desperate need
of love (it is 2023 and video uploads are limited to 4gb with the flakiest
upload process known to man).


It was also pointed out to me on irc, that many critical workflows in the
community depend on toolforge tools that have very limited volunteer
maintainership. A sort of https://xkcd.com/2347/ situation. Just because
they're not "production" we often pretend they don't exist. Regardless of
how we label them, in the end it doesn't make a difference to the end user,
and the fragility of that ecosystem is a form of technical debt that is
often overlooked.


So i guess it all depends on what is meant by "technical debt"
--
Brian

On Friday, April 14, 2023, Andre Klapper  wrote:

> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
> > > "I think there are lots of promising opportunities to incentivise
> > > people to pay off technical debt and make our existing stack more
> > > sustainable. Right now there are no incentives for engineers in
> > > this regard."
> >
> > Interesting. Personally to me, it can sometimes feel like we never
> > stop talking about technical debt. While I think paying off technical
> > debt is important, at times I feel like we've swung in the opposite
> > direction where we are essentially rewriting things for the sake of
> > rewriting things.
>
> "Technical debt" spontaneously brings the following items to my little
> mind. They should not be about rewriting but rather "maintenance":
>
>  * librsvg for SVG rendering is a five year old version:
>https://phabricator.wikimedia.org/T193352 /
>https://phabricator.wikimedia.org/T265549
>  * Graph extension on old Vega version 2.6.3: see subtasks of
>https://phabricator.wikimedia.org/T292341
>  * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
>in 2012): https://phabricator.wikimedia.org/T178146
>  * 3D extension on a five year old three.js library in
>https://phabricator.wikimedia.org/T277930#7636129
>  * Removing the OpenStackManager extension from wikitech.wm.org:
>https://phabricator.wikimedia.org/T161553
>  * Removing WVUI from MediaWiki
>core: https://phabricator.wikimedia.org/T310244
>  * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
>https://phabricator.wikimedia.org/T138401
>  * Undeploy VipsScaler from Wikimedia wikis:
>https://phabricator.wikimedia.org/T290759
>  * https://phabricator.wikimedia.org/T151393 (a non-public task)
>
> This is not a complete list. Plus there are also separate "waiting for
> someone to make a decision" and "improving communicating & documenting
> already-made decisions" categories which would be different lists.
>
> Of course there might be valid reasons not to look into some of this
> technical debt (other higher priorities, high risk, complexity, etc).
>
> Cheers,
> andre
>
> --
> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
> ___
> Wikitech-l mailing list -- wikitec...@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists
> .wikimedia.org/
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/BZP2SHMGT4KYUJ4DPIUVMTZRJEW5QXGE/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Opportunities open for the Ombuds commission and the Case Review Committee

[Brian Choo]

Dear Wikimedians,

This message is to announce the seating of new members on the Interim Case
Review Committee (CRC).

For background, the Case Review Committee is a volunteer committee composed
of 10 experienced volunteers from across the Wikimedia movement. The CRC
reviews eligible Trust & Safety decisions that are appealed either by those
who originally requested the investigation or those who have been
sanctioned by them. For more information, please refer to the page about
the CRC on Meta-Wiki.[1]

Following the 2023 call for applications for the CRC,[2] the committee has
seated three new members, for a total of ten members. New members will
serve two-year terms. The terms of the seven current members have been
extended until 31 December 2023.

The ten members combined have nearly 1.5 million edits on various wikis and
100 years of experience on our projects. They represent membership on seven
different home wikis and numerous affiliates. They collectively hold
functionary rights across multiple projects, including administrator,
bureaucrat, checkuser, oversight, and advanced global permissions. Between
them, they have been involved in many key committees and organized groups.

For more information on the Case Review Committee’s work, please see the
reports page.[3]

I'd like to thank everyone who participated in this process for their
contributions, especially those who volunteered for this important role.

On behalf of the Wikimedia Foundation’s Committee Support team,

Brian Choo
IP and Litigation Case Specialist
Wikimedia Foundation


[1] https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee
[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Legal_department/Announcement/2023_OC_and_CRC_appointments_process
[3]
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Monthly_reports#2022


On Tue, Dec 13, 2022 at 10:35 AM Karen Brown  wrote:

> Hi folks,
>
> This is just a reminder that we are still accepting applications for
> membership on the Ombuds Commission and the Case Review Committee. Both are
> important committees with a vital role in community governance.
>
> If you are interested in serving in either capacity listed above, please
> write in English to the Trust and Safety team at  ca[image: @]wikimedia[image:
> .]org   (to apply to the OC) or to the Legal Team at  legal[image: @]
> wikimedia[image: .]org   (to apply to the CRC) with information about:
>
>
>- Your primary projects
>- Languages you speak/write
>- Any experience you have serving on committees, whether movement or
>non-movement
>- Your thoughts on what you could bring to the OC or CRC if appointed
>- Any experience you have with the Checkuser or Oversight tools (OC
>only)
>- Any other information you think is relevant
>
>
> Please also be sure to include your username in the email!
>
> The deadline for applications is 31 December 2022 in any timezone.
>
> Regards,
> Karen
>
> On Mon, Oct 3, 2022 at 8:54 AM Karen Brown  wrote:
>
>>
>> You can find this message translated into additional languages on
>> Meta-wiki.
>> <https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_Legal_department/Announcement/2023_OC_and_CRC_appointments_process>
>>
>> More languages
>> <https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_Legal_department/Announcement/2023_OC_and_CRC_appointments_process>
>> • Please help translate to your language
>> <https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Wikimedia+Foundation+Legal+department%2FAnnouncement%2F2023+OC+and+CRC+appointments+process==page=>
>>
>> Hi everyone! The Ombuds commission (OC) and the Case Review Committee
>> (CRC) are looking for members. People are encouraged to nominate themselves
>> or encourage others they feel would contribute to these groups to do so.
>> There is more information below about the opportunity and the skills that
>> are needed.
>>
>> About the Ombuds commission
>>
>> The Ombuds commission (OC) works on all Wikimedia projects to investigate
>> complaints about violations of the privacy policy, especially in use of
>> CheckUser <https://meta.wikimedia.org/wiki/CheckUser_policy> and
>> Oversight <https://meta.wikimedia.org/wiki/Oversight_policy> (also known
>> as Suppression) tools. The Commission mediates between the parties of the
>> investigation and, when violations of the policies are identified, advises
>> the Wikimedia Foundation on best handling. They may also assist the General
>> Counsel, the Chief Executive Officer, or the Board of Trustees of the
>> Foundation in these investigations when legally necessary. For more on the
>> OC's duti

[Wikimedia-l] Re: [Foundation-l] Improving search in Wikipedia through quality and concept discovery

[Brian Mingus]

Your the search guy?

Why did you marginalize my work?

On Sun, Nov 1, 2009 at 9:15 AM Robert Stojnic  wrote:

>
> Hi Brian,
>
> I'm not sure this is foundation-l type of discussion, but let me give a
> couple of comments.
> I took the liberty of re-running your sample query "hippie" using google
> and built-in search on simple.wp, here are the results I got for top 10
> hits:
>
> Google:  [1]
> Hippie, Human Be-In, Woodstock Festival, South Park, Summer of Love,
> Lysergic acid diethylamide, Across the Universe (movie), Glam rock,
> Wikipedia:Simple talk/Archive 27, Morris Gleitzman
>
> simple.wikipedia.org: [2]
> Hippie, Flower Power, Counterculture, Human Be-In, Summer of Love,
> Woodstock Festival, San Francisco California, Glam Rock, Psychedelic
> pop, Neal Cassady
>
> LDA (your method results from your e-mail):
> Acid rock, Aldeburgh Festival, Anne Murray, Carl Radle, Harry Nilsson,
> Jack Kerouac, Phil Spector, Plastic Ono Band, Rock and Roll, Salvador
> Allende, Smothers brothers, Stanley Kubrick
>
> Personally, I think the results provided by the internal search engine
> are the best, maybe even slightly better than google's, and I'm not sure
> what kind of relatedness LDA captures.
>
> If we were to systematically benchmark these methods on en.wp I think
> google would be better than internal search, mainly because it can
> extract information from pages that link to wikipedia (which apparently
> doesn't work as well for simple.wp). But that is beside the point here.
>
> I think it is interesting that you found that certain classes of pages
> (e.g. featured articles) could be predicted from some statistical
> properties, although I'm not sure how big is your false discovery rate.
>
> In any case, if you do want to work on improving the search engine and
> classification of articles, here are some ideas I think are worth
> pursuing and problems worth solving:
>
> * integrating trends into search results - if one searches for "plane
> crash" a day after a plane crashes, he should get first hit that plane
> crash and not some random plane crash from 10 years ago - we can
> conclude this is the one he wants because it is likely that this page is
> going to get a lots of page hits. So, this boils down to: integrate page
> hit data into search results in a way that is robust and hard to
> manipulate (e.g. by running a bot or refreshing a page million times)
>
> * morphological and context-dependent analysis, if a user enters a query
> like "douglas adams book" what are the concepts in this query? Should we
> group the query like [(douglas adams) (book)] or [(douglas) (adams
> book)]? Can we devise a general rule that will quickly and reliably
> separate the query into parts that are related to each other, and then
> use those to search through the article space to find the most relevant
> articles?
>
> * technical challenges: can we efficiently index expanded article with
> templates, can we make efficient category intersection (w/o subcategories)
>
> * extracting information: what kinds of information is in wikipedia, how
> do we properly extract it and index it? What about chemical formulas,
> geographical locations, computer code, stuff in templates, tables, image
> captions, mathematical formulas
>
> * how can we improve on the language model? Can we have smarter stemming
> and word disambiguation (compare shares in "shares and bonds" vs  "John
> shares a cookie"). What about synonyms and acronyms? Can we improve on
> the language model "did you mean..." is using to correlate related words?
>
> Hope this helps,
>
> Cheers, robert (a.k.a "the search guy")
>
> [1] http://www.google.co.uk/search?q=hippie+site%3Asimple.wikipedia.org
> [2]
>
> http://simple.wikipedia.org/w/index.php?title=Special%3ASearch=Hippie=Search
>
>
> Brian J Mingus wrote:
> > This paper (first reference) is the result of a class project I was part
> of
> > almost two years ago for CSCI 5417 Information Retrieval Systems. It
> builds
> > on a class project I did in CSCI 5832 Natural Language Processing and
> which
> > I presented at Wikimania '07. The project was very late as we didn't send
> > the final paper in until the day before new years. This technical report
> was
> > never really announced that I recall so I thought it would be
> interesting to
> > look briefly at the results. The goal of this paper was to break articles
> > down into surface features and latent features and then use those to
> study
> > the rating system being used, predict article quality and rank results
> in a
> > search engine. We used the [[random f

[Wikimedia-l] Re: Call for applicants: Interim Trust & Safety Case Review Committee

[Brian Choo]

Hi everyone!

The call for applicants for the Interim Trust & Safety Case Review
Committee is now open until 4 March 2022. Please see the below email for
details (or here <
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Call_for_applicants
>).

Best,
Brian Choo
Facilitator for the Interim Trust & Safety Case Review Committee
Wikimedia Foundation

On Wed, Feb 9, 2022 at 8:30 PM Brian Choo  wrote:

> Dear Wikimedians,
>
> In a nutshell: This is the second call for applications to volunteer for
> the Interim Trust & Safety Case Review Committee (hereafter Case Review
> Committee, or CRC). The CRC will stand until the Universal Code of Conduct
> escalation process pathways are defined and established. Text below
> explains what the committee does and what is required of applicants. If it
> resonates with you, please apply. Please forward this to any groups you
> think appropriate! This call for applicants will be open until February
> 25. (A translatable version of this announcement is on Meta at [1].)
>
>
> *
>
>
> In 2020, the Board of Trustees asked the Wikimedia Foundation to put
> together an interim volunteer community review process to help support
> Trust & Safety behavioral investigations by ensuring that there is a
> functionary appeal process available for borderline cases.[2] For clarity,
> this is to appeal cases handled by the Foundation’s professional Trust &
> Safety staff. It is not to appeal governance decisions by community
> administrators or governance bodies.
>
>
> A permanent review process for Trust & Safety team cases will be created
> later as part of the final stages of the Universal Code of Conduct, but
> this quickly constituted interim Case Review Committee will be asked to
> serve until it is functional. As of February 2022, the interim Case Review
> Committee will serve until the end of the calendar year 2022, or when a
> permanent process is ready to supersede it. This is a critical layer of
> oversight to ensure that Foundation actions are fair and unbiased and that
> the Foundation doesn’t step in where it is not necessary to do so.
>
>
> We are looking for functionaries and experienced volunteers with an
> interest in joining this group. If the work resonates and you qualify,
> please apply.
>
>
>
> There is a page on Meta with more information about how the CRC works.[3]
> In brief, it reviews the case files of qualifying Trust & Safety
> investigations that are appealed either by the person who requested the T
> investigation or by a person sanctioned as a result of one. We anticipate
> that, during active appeals, members may need to dedicate about 5 hours of
> work a week reviewing case files. Since it began accepting appeals in
> September 2021, however, the CRC has had a light workload.[4]
>
>
> You will be asked to meet with the rest of the group on a quarterly basis
> to discuss the committee itself and how it might be improved. In its first
> year of operation, the CRC has provided feedback to Wikimedia Foundation
> Trust & Safety on how it could improve some of its processes.
>
>
> There are a few very specific requirements for those who are accepted. If
> you are interested in applying, we ask that you first read the Committee
> charter and decide if you are willing and able to abide by the conditions
> of membership and if you meet the criteria outlined there.[3] If you then
> want to apply, please write to le...@wikimedia.org using “Case Review
> Committee” in your subject line. Please include your username, your
> credentials, and a statement of what you hope to bring to the role.
> Credentials in this case refers to community background - have you been an
> administrator? A member of an arbitration committee? Where or when? What
> experiences do you think have prepared you to do this well? Reference to
> professional credentials will also be taken into account, but does require
> legal identification so that it may be confirmed. Otherwise, we will only
> be asking for legal identification from applicants who are finalists.
>
>
> Unfortunately, English language fluency is a must. While we hope to get as
> much linguistic diversity as possible, Trust & Safety’s case files are
> lengthy documents written in complex English, and expedience and current
> availability of resourcing does not make it possible to provide
> translations for the interim process.
>
>
> The CRC serves an important role in collaborations between Trust & Safety
> staff and volunteers to help make sure we get the balance right in
> protecting communities - both in supporting community members and
> recognizing community autonomy.
>
>
> *Please submit your appl

[Wikimedia-l] Call for applicants: Interim Trust & Safety Case Review Committee

[Brian Choo]

Dear Wikimedians,

In a nutshell: This is the second call for applications to volunteer for
the Interim Trust & Safety Case Review Committee (hereafter Case Review
Committee, or CRC). The CRC will stand until the Universal Code of Conduct
escalation process pathways are defined and established. Text below
explains what the committee does and what is required of applicants. If it
resonates with you, please apply. Please forward this to any groups you
think appropriate! This call for applicants will be open until February 25. (A
translatable version of this announcement is on Meta at [1].)


*


In 2020, the Board of Trustees asked the Wikimedia Foundation to put
together an interim volunteer community review process to help support
Trust & Safety behavioral investigations by ensuring that there is a
functionary appeal process available for borderline cases.[2] For clarity,
this is to appeal cases handled by the Foundation’s professional Trust &
Safety staff. It is not to appeal governance decisions by community
administrators or governance bodies.


A permanent review process for Trust & Safety team cases will be created
later as part of the final stages of the Universal Code of Conduct, but
this quickly constituted interim Case Review Committee will be asked to
serve until it is functional. As of February 2022, the interim Case Review
Committee will serve until the end of the calendar year 2022, or when a
permanent process is ready to supersede it. This is a critical layer of
oversight to ensure that Foundation actions are fair and unbiased and that
the Foundation doesn’t step in where it is not necessary to do so.


We are looking for functionaries and experienced volunteers with an
interest in joining this group. If the work resonates and you qualify,
please apply.



There is a page on Meta with more information about how the CRC works.[3]
In brief, it reviews the case files of qualifying Trust & Safety
investigations that are appealed either by the person who requested the T
investigation or by a person sanctioned as a result of one. We anticipate
that, during active appeals, members may need to dedicate about 5 hours of
work a week reviewing case files. Since it began accepting appeals in
September 2021, however, the CRC has had a light workload.[4]


You will be asked to meet with the rest of the group on a quarterly basis
to discuss the committee itself and how it might be improved. In its first
year of operation, the CRC has provided feedback to Wikimedia Foundation
Trust & Safety on how it could improve some of its processes.


There are a few very specific requirements for those who are accepted. If
you are interested in applying, we ask that you first read the Committee
charter and decide if you are willing and able to abide by the conditions
of membership and if you meet the criteria outlined there.[3] If you then
want to apply, please write to le...@wikimedia.org using “Case Review
Committee” in your subject line. Please include your username, your
credentials, and a statement of what you hope to bring to the role.
Credentials in this case refers to community background - have you been an
administrator? A member of an arbitration committee? Where or when? What
experiences do you think have prepared you to do this well? Reference to
professional credentials will also be taken into account, but does require
legal identification so that it may be confirmed. Otherwise, we will only
be asking for legal identification from applicants who are finalists.


Unfortunately, English language fluency is a must. While we hope to get as
much linguistic diversity as possible, Trust & Safety’s case files are
lengthy documents written in complex English, and expedience and current
availability of resourcing does not make it possible to provide
translations for the interim process.


The CRC serves an important role in collaborations between Trust & Safety
staff and volunteers to help make sure we get the balance right in
protecting communities - both in supporting community members and
recognizing community autonomy.


*Please submit your application by the end of February 25, 2022.*


[1]
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Call_for_applicants


[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/May_2020_-_Board_of_Trustees_on_Healthy_Community_Culture,_Inclusivity,_and_Safe_Spaces


[3]
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Charter


[4]
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Monthly_reports




--
Brian Choo
Facilitator for the Interim Trust & Safety Case Review Committee
Wikimedia Foundation
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https:/

[Wikimedia-l] Wikimedians of Chicago 2019-20 report submitted

[Brian Choo]

 Hello everyone,

The Wikimedians of Chicago User Group has submitted its 2019-20 activities
report:
https://meta.wikimedia.org/wiki/Wikimedians_of_Chicago_User_Group/2019-2020_Activities_Report

Warm regards,
Brian Choo
___
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>

[Wikimedia-l] Announcement of new Foundation office action appeals process

[Brian Choo]

Dear Wikimedians,

This announcement is to increase awareness of a new addition to the
Wikimedia Foundation's office actions appeals process through the Interim
Trust & Safety Case Review Committee (CRC).[1][2] It includes a new way for
some editors who have sought sanction and some editors who have been
sanctioned by the Wikimedia Foundation to appeal.

Historically, some office actions have been appealable through the Trust &
Safety team. The Interim Trust & Safety Case Review Committee (CRC) was
created to provide community oversight of the appeals process. The CRC has
10 volunteer Wikimedia community members and will function until the
Universal Code of Conduct becomes effective in approximately mid-2021, when
we hope to have a more permanent process in place. As mentioned in the
CRC’s charter, the committee will be able to review office actions which
were closed by the Foundation with action or inaction, except statutory,
regulatory, employment, and legal cases as defined by Foundation
attorneys.[3]

The office actions policy is a set of guidelines and procedures regarding
official changes to or removals of content on the Wikimedia projects, or
actions against specific individuals, performed by Foundation staff members
and under the authority of the Wikimedia Foundation, upon receipt of one or
multiple complaints from the community or the public, or as required by
law. Complaints that may lead to enforcement of office actions may include,
but are not limited to, privacy violations, child protection, copyright
infringement or systematic harassment. All office actions are performed
pursuant to the Terms of Use.

Appeals of office actions may be submitted to the CRC by anyone involved in
the office action via email at appeals[at]wikimedia.org. Detailed
instructions on how to appeal may be found on the CRC’s meta page.[1] Some
office cases are not eligible for review. A Foundation attorney will check
each case where appeal is requested to determine its eligibility before
turning over the case files to the committee. For transparency, the
committee chair will be able to review those requests and will therefore
have insight into how many cases are eligible or not.

Please refer to the CRC’s page on meta.wikimedia.org for further
information. You are encouraged to inform your community about this new
appeals process. If you have questions for or about the committee, please
put them on the CRC talk page on Meta or email me at
bchoo-ctr[at]wikimedia.org.[4] The Meta talk page also contains questions
that have already been asked and answered. I will find answers to your
questions and post responses on the Meta talk page.

On behalf of the committee,
Brian Choo
Interim Case Review Committee Facilitator

[1] https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee
[2] https://meta.wikimedia.org/wiki/Office_actions
[3]
https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee/Charter
[4]
https://meta.wikimedia.org/wiki/Talk:Trust_and_Safety/Case_Review_Committee

-- 
Brian Choo
Interim Case Review Committee Facilitator
Wikimedia Foundation
___
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] [Wmfall] New Developers Quarterly Report's first edition

[Brian Wolff]

Fae wrote:
>Does the minus symbol in "-60.0%" mean anything? Being a retention
>percentage, I do not understand how it can be negative unless
>potential volunteers are getting rejected at the door before they can
>sign-up. Could that be corrected?

My understanding is that this means that the rentention percentage was
60% (or is it percentage points?) less than it was this time last
year.

So its now 5%, but this time last year it was 12%.

--
bawolff

___
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, 

Re: [Wikimedia-l] [Wmfall] New Developers Quarterly Report's first edition

[Brian Wolff]

On Tue, Oct 17, 2017 at 7:03 PM, Srishti Sethi  wrote:
> Hello everyone,
>
>
> I would like to share the first edition of the New Developers Quarterly
> Report that the Developer Relations team has produced. This report covers
> metrics, survey analysis and lessons learned from new developers focused
> activities in the previous quarter (July-September 2017).
>
>
> If you have questions and feedback that you would like to share with us,
> please add them on the discussion page.
>
>
> To receive a notification when a new report is published, subscribe here.
>
>
> We plan to release a report every quarter and take action items identified
> from the key findings for improving our existing methods and processes. The
> next release will be in January 2018.
>
>
> If you have any questions, comments, and concerns, we will be more than
> happy to hear them!
>
>
> Thanks,
>
> Srishti
>
>

From the report:

>Percentage of volunteers active one year (± 3 months) after their first 
>contribution, out of all new volunteers attracted one year ago (between 
>April–June >2016). (Source: Calculation on data)
>
>QoQ: -26.5%. YoY: -60.0%

That's kind of scary

--
bawolff

___
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, 

Re: [Wikimedia-l] [Wikitech-l] IRC office hours: Shared hosting

[Brian Wolff]

On 12/20/15, James Salsman  wrote:
> Were there any objections to my request below?
>

Yes. As MaxSem said earlier[1], its basically being ignored as being
totally irrelevant to the topic at hand. (To be clear: Third-party
does not mean people who are doing work on Wikimedia sites that aren't
WMF. Third party = Wikis that have nothing to do with Wikimedia wikis
(e.g. wikia, wikihow, uncyclopedia etc))

If you want to get Dispenser his hard disk space, you should take it
up with the labs people, or at the very least some thread where it
would be on-topic.

> Can we also please hire additional database, system, and if necessary
> network administration support to make sure that the third party spam
> prevention bot infrastructure is supported more robustly in the future?

Then by definition it wouldn't be a third-party spam framework if WMF
was running it.

--
-bawolff

[1] https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084326.html
[Linking because this thread is super-cross posted, and some people
are going to be confused as to what I'm referring to]

___
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] Changes in Engineering leadership

[Brian Wolff]

Another thought: perhaps more investment could be made in providing career
development support for our volunteers of all kinds. It's relatively common
in the United States for organizations with lots of volunteers to put some
investment explicitly into helping the volunteers develop skills snd
experience that are useful for both their voluntary and paid work CVs. If
more of that kind of investment was made by WMF, volunteering would be more
attractive *and* WMF would benefit by having more ability to fill paid
positions from the ranks of volunteers.

Pine

I'm curious, concretely speaking, what do you have in mind?

FWIW, I'm very thankful to say that Wikimedia has given me many
opportunities to develop skills etc. When I made my first edit I
didn't know how to program, now that's what I do for living. Much of
that is thanks to help and guidance of many Wikimedians. Obviously
that's a different type of mentoring than you're suggesting, but
nonetheless much of what I know can be directly attributed to
mentoring by various people associated with the movement.

--
bawolff

___
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] Unsolicieted email from wikimedia research

[Brian Wolff]

So as part of 
https://meta.wikimedia.org/wiki/Research:Increasing_article_coverage
, it appears that unsolicited emails have been sent out encouraging
people to translated articles into needed languages.

I am all for improving article coverage, etc, but I'm concerned about
the use of user account emails to send unsolicited mail that the user
has not opted into. I think use of user email addresses for purposes
other than the user has agreed to, is not ok.

--
bawolff

___
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] [Wikimedia Announcements] Securing access to Wikimedia sites with HTTPS

[Brian Wolff]

I should also mention that while we try to be as transparent as possible in
all our work (including holding community consultations around all major
legal policies and providing frequent updates on our work), there are very
limited situations where public discussions could actually hurt free access
to Wikipedia. If you have thoughts about the evolving censorship landscape,
feel free to email me directly, if possible via encrypted email.

I find the secrecy surrounding the HTTPS rollout to be odd (To put it mildly).

What are we worried about. A censor who follows wikimedia-l, but not
the press release the WMF issued?

All the technical details are public (The git repo is public. Not to
mention the whole fact we're using https is going to be painfully
obvious when you visit the site, and its in https). We aren't doing
anything surprising, we are in the process of simply following what
many people consider best practices. We've publicly stated our
intention to do this for years now. And its pretty obvious what the
next steps of the deployment are going to be. The only thing really
being kept secret is the timetable, and which specific projects are up
next.

--
bawolff

___
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] [Wikimedia Announcements] Securing access to Wikimedia sites with HTTPS

[Brian Wolff]

To be truly free, access to knowledge must be secure and uncensored. At the
Wikimedia Foundation, we believe that you should be able to use Wikipedia
and the Wikimedia sites without sacrificing privacy or safety.

Today, we’re happy to announce that we are in the process of implementing
HTTPS https://en.wikipedia.org/wiki/HTTPS to encrypt all Wikimedia
traffic. We will also use HTTP Strict Transport Security
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (HSTS) to
protect against efforts to ‘break’ HTTPS and intercept traffic. With this
change, the nearly half a billion people who rely on Wikipedia and its
sister projects every month will be able to share in the world’s knowledge
more securely.

Well this is a great move, and I applaud it (About time :), until such
a time as IPSec is fully deployed, isn't that a little misleading as
to the actual security afforded by this change? There is quite a lot
of evidence that the NSA is slurping up data from unsecured inter data
centre links of other people [1], seems unlikely that they are
ignoring us.

I also think we should have a more balanced position on how much
privacy TLS actually provides in the context of Wikipedia, so that
users can be properly informed. Sure, TLS is a step in the right
direction, probably stops most less well funded adversaries, but its
not a panacea. In the case of Wikipedia, the content of every page is
not static, but it is totally public, so Wikipedia is probably the
ideal target of traffic analysis type attacks against SSL. That sort
of thing is almost certainly more expensive than just grepping
packets, but surely seems to be within the budget of the NSA to do,
even in a bulk manner (Assuming that non-targeted surveillance by a
state level adversary is the unspoken threat model we're trying to
defend against).

--
bawolff

[1] https://en.wikipedia.org/wiki/Muscular_%28surveillance_program%29

___
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] Fwd: A new structure for WMF Engineering.

[Brian Wolff]

 In particular, I wanted to share more about the plans for the Community
 Tech team. The creation of this team is a direct response to community
 requests for more technical support. Their mission is to understand and
 support the technical needs of core contributors, including improved
 support for expert-­focused curation and moderation tools, bots, and other
 features. Their mandate is to work closely with you, and the Community
 Engagement department, to define their roadmap and deliverables. We are
 hiring for a leader for this team, as well as additional engineers. We will
 be looking within our communities to help. Until then, it will be incubated
 under Toby Negrin, with support from Community Engagement.

I look forward to seeing how this works out. I sometimes worry that it
seems like over the years that developers have become more and more
separate from the community. Our community is our heart; It is why
we are all here. Having teams dedicated to working closely with our
communities sounds like an excellent idea.


--
bawolff

___
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] Announcing: The Wikipedia Prize!

[Brian]

I'm sure many of you recall the Netflix Prize
http://en.wikipedia.org/wiki/Netflix_Prize. This is that, for Wikipedia!

Although the initial goal of the Netflix Prize was to design a
collaborative filtering algorithm, it became notorious when the data was
used to de-anonymize Netflix users. Researchers proved that given just a
user's movie ratings on one site, you can plug those ratings into another
site, such as the IMDB. You can then take that information, and with some
Google searches and optionally a bit of cash (for websites that sell user
information, including, in some cases, their SSN) figure out who they are.
You could even drive up to their house and take a selfie with them, or
follow them to work and meet their boss and tell them about their views on
the topics they were editing.

Here, we'll cut straight to the privacy chase. Using just the full history
dump of the English Wikipedia, excluding edits from any logged-in users,
identify five people. You must confirm their identities with them, and
privately prove to me that you've done this. I will then nominate you as
the winner and send you one million Satoshis (the smallest unit of Bitcoin,
times 1 million), in addition to updating this thread.

I suspect this challenge will be very easy for anyone who is determined.
Indeed, even if MediaWiki no longer displayed IP addresses, there would
still be enough information to identify people. Completely getting rid of
the edit history would largely solve the problem. In the mean time, this
Prize will serve as a reminder that when Wikipedia says Your IP address
will be publicly visible if you make any edits. what they mean is, People
will probably be able to figure out where you live and embarrass you.

An extra million Satoshis for each NSA employee that you identify. A full
bitcoin if you take a selfie with them.

Let the games begin!

Brian Mingus
___
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] [Wikitech-l] Types of allowed projects for grant funding (renamed)

[Brian Wolff]

On 2/21/15, Pine W wiki.p...@gmail.com wrote:
 (Now continuing this discussion on Wikimedia-l also, since we are
 discussing grant policies.)

 For what it's worth, I repeatedly advocated for allowing IEG to support a
 broader range of tech projects when I was on IEGCom. I had the impression
 that there was a lot of concern about limited code review staff time, but
 it serms to me that WMF has more than enough funds to to pay for staffing
 for code review if that is the bottleneck for tech-focused IEGs (as well as
 other code changes).

 I also think that the grant scope policies in general seem too conservative
 with regard to small grants (roughly $30k and under). WMF has millions of
 dollars in reserves, there is plenty of mission-aligned work to be done,
 and WMF itself  frequently hires contractors to perform technical,
 administrative, communications, legal and organizing work. It seems to me
 that the scope of allowed funding for grants should be similar to the scope
 of allowed work for contractors, and it would serve the purposes that
 donors have in mind when they donate to WMF if the scope of allowed
 purposes for grants is expanded, particularly given WMF's and the
 community's increasing skills with designing and measuring projects for
 impact.

That's actually debatable. There's grumbling about WMF code review
practices not being sufficient for WMFs own code (or as sufficient as
some people would like), and code review is definitely a severe
bottleneck currently for existing volunteer contributions.

However that's not a reason to have no IEG grants for tech projects
ever, its just a reason for code review to be specifically addressed
in the grant proposal, and for the grantee to have a plan. Maybe that
plan involves having a (volunteer) friend who has +2 do most of the
code review. Maybe that plan involves a staff member getting his
manager to allow him/her to have 1 day a week to review code from this
grant (Assuming that the project aligns with whatever priorities that
staff member's team has, such an arrangement does not seem
unreasonable). Maybe the grant includes funds for hiring code review
resources (ie non-wmf people with +2. We exist!). Maybe there is some
other sort of arrangement that can be made that's specific to the
project in question. Every project is different, and has different
needs.

I do not think expecting WMF engineering to devote significant
resources to IEG grants is viable, as I simply doubt its something
that WMF engineering is willing to do (And honestly I don't blame
them. They have their own projects to concentrate on.). IEG's are
independent projects, and must be able to stand mostly on their own
with minimal help. I do think getting WMF to perform the final once
over for security/performance of a project prior to deployment, at the
end, is reasonable (provided the code follows MW standards, is clean,
and has been mostly already reviewed for issues by someone in our
community). At most, I think bringing back 20% time, with that time
devoted to doing code review of IEGs, would be the most that we could
reasonably expect WMF to devote (but even if they didn't want to do
that, I don't think that's a reason not to do IEG tech grants).

Code review is an inherent risk to project success, much like user
acceptability. It should be planned around, and considered. We should
not give up just because there is risk. There is always risk. Instead
we must manage risk as best we can.


--bawolff

___
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