[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

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, 

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

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

[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  to encrypt all Wikimedia
>traffic. We will also use 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, 

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, 

Re: [Wikimedia-l] [Wikitech-l] Types of allowed projects for grant funding (renamed)

[Brian Wolff]

On 2/21/15, Pine W  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,