[Wikitech-l] Re: Reflecting on my listening tour

[Dan Garry (Deskana)]

Despite agreeing wholeheartedly that technical debt, product debt,
ownership, and maintenance are persistent problems, here's a story about
when this *didn't* happen, which maybe we can learn from.

Disclaimer: this is from my memory of 2014! Warning, potential inaccuracy
and rose-tinted glasses!

We had a global login system (single user login, or SUL) but it was in a
bit of disarray. There were many local accounts disconnected from global
ones because they were made before the global login system, many username
conflicts that went unaddressed. Users were given some tools to resolve
these conflicts, but not enough to actually finalise the whole thing. We
all agreed it needed solving. We all new the end state we wanted. But,
there were multiple technical and product solutions to get there, and no
actual concerted effort to do it. Many of the username conflicts were
between long-time community members, so we were sure to get some dedicated
volutneers angry no matter how we did it. So it sat in limbo, annoying
everyone, and never happening. Sound familiar?

Around then, WMF leadership introduced a new prioritisation framework: "top
5 priorities". This was a ranked list of projects that were considered to
be more important than others for that quarter. It was intended as a first
attempt to combat the "if everything's important, nothing's important"
syndrome. You can't argue with a ranked list! And, number one on the list
for the first quarter, not something new and shiny, but an old one: the SUL
finalisation ! Sort it all
out, once and for all.

Erik Möller (the then VP of Product and Engineering, de facto CPO and CTO
really, reflecting on it) asked me to be the product manager. I was very
inexperienced as a PM but had been an editor for eight years, so I
understood the problem well. Still, I wondered how we were possibly going
to achieve anything, the project had been "in progress" for years with
almost no progress. Erik asked me what I needed to make it happen. I got
some advice, and said I need a systems designer, a systems architect, an
engineer that knows the community well, and a community liaison. Erik went
and had the hard conversations with the people that currently needed said
people ("It's top priority this quarter, the other stuff has to wait.") and
went and got those people. We figured it all out, and we did it, once and
for all (timeline reduced, it did still take multiple quarters, but we knew
that going in). Everyone now has a fully global account!

Now, times were simpler back then. This exact technique wouldn't work now,
for multiple reasons. But, I wonder what we can learn from this as an
organisation. What would it take to repeat this achievement?

Dan

P.S. Some of that team I worked with are still on this list. Hello! Thank
you for the growth as a PM that I got out of that project, and for beating
my inexperienced head around a bit until it got more experienced.
___
Wikitech-l mailing list -- wikitech-l@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/

[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator

[Dan Garry (Deskana)]

On Fri, 24 Feb 2023 at 11:20, Andre Klapper  wrote:

>  * Personally I also assume Lowest priority is sometimes used instead
>of honestly declining a task (means: "this is not a good idea"[5]).
>But of course that is rather hard to prove.
>

This is anecodal, but when I was a product manager at the WMF, I did this
sometimes. As is true in any company or project, there will always be
tickets that contain valid bugs or requests, but the reward per unit effort
makes them not worth fixing. I often tried to close these as declined to
reflect that reality, but not infrequently someone outside the team would
reopen the ticket. The path of least resistance to stop team workboards
being filled with tickets that would never be actioned was to mark them as
lowest priority, and then use a filter to remove those tickets from our
views of the board.

I don't particularly have a view one way or the other on removal of the
"lowest" priority. The workflow I described above wouldn't really change;
"low" could just become the new "lowest", but people wouldn't find it
demoralising, I suppose?

Dan
___
Wikitech-l mailing list -- wikitech-l@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/

[Wikitech-l] Re: Discussing two feature requests?

[Dan Garry (Deskana)]

Hi Siegfried,

You are welcome to send emails to this mailing list in German, if you would
prefer. Most people on this list write in English because it is understood
by the most people and it has the largest audience, but this is a
multilingual community and posts in any language are allowed.

Of course, you are also welcome to email privately in German if you would
prefer to do that.

Dan

On Sun, 26 Jun 2022 at 07:22, Siegfried Schmitt 
wrote:

> Hello Everyone,
>
> I would like to propose two - probably new - features for MediaWiki.
> Since my native language is German, I would like to discuss these
> features with some developers from Germany, Austria, or Switzerland.
> My Englisch is really bad and therefore, I would prefer to discuss in
> German language. Please feel free to contact me via e-mail.
>
> Best regards,
>
> Siegfried
>
> --
> siegfried.schm...@web.de
> ___
> Wikitech-l mailing list -- wikitech-l@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/
>
___
Wikitech-l mailing list -- wikitech-l@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/

[Wikitech-l] Re: Why does the train start on Tuesday?

[Dan Garry (Deskana)]

On Tue, 22 Jun 2021 at 23:10, Jon Robson  wrote:

> Apologies if I didn't make myself clear, but it seems I didn't given both
> Amir's comments. I am very happy that we have these, and my question was *not
> *why do we have them, but rather* why do we only have 2*. I want more of
> them and every time I've asked why we don't have more, I've been told it's
> a community decision and that seems odd to me.
>

It's a community decision in the sense that it wasn't something the WMF
decided for them, it was those communities decided it for themselves.
They're open to it probably as a result of being generally less
conservative when it comes to changes, and more willing to try things out
early. But, it's not a community decision in the sense that you, as staff,
can't get involved and try to recruit more wikis!

So, if other wikis are asked if they want to be in group 1, understand the
advantages and disadvantages of that, and they said yes, I doubt anyone
would raise any objections. Having more wikis in that group to test things
on early would definitely be a benefit.

Amir's suggestion to contact wikis that have been open to Growth features,
like Czech and Korean (I think?), sounds like a great one, especially if
there are community ambassadors that could help explain what it means to be
in group 1.

Dan
___
Wikitech-l mailing list -- wikitech-l@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/

Re: [Wikitech-l] 1st CfP: SEMANTiCS 2021 EU || Sep 6 - 9, 2021 || Amsterdam, The Netherlands

[Dan Garry (Deskana)]

I agree with Max. This conference is pretty much irrelevant for this list,
as it has almost nothing to do with the topic of wikis generally. The only
connection this conference has to this list is the existence of the
Semantic MediaWiki extension; this list could quickly be overrun with
conference emails if they were allowed on the basis of the existence of a
MediaWiki extension related to the topic area.

Sebastian, there are a few Semantic MediaWiki email lists
,
why don't you try posting this there? You might get a lot more interest, as
the audience there will be very interested in the Semantic Web. :-)

Dan

On Fri, 25 Dec 2020 at 16:18, Andreas Papacharalampous 
wrote:

> i don't mind a crosspost, but probably not a good idea to vent your
> frustration against a crosspost on a public list IMO.
>
> --andreas
> he/him
>
>
>
> On Fri, Dec 25, 2020 at 10:53 AM Andrew Krizhanovsky <
> andrew.krizhanov...@gmail.com> wrote:
>
>> Sorry Max, but this information was interesting for me :)
>>
>> Best regards,
>> Andrew Krizhanovsky.
>>
>>
>> On Fri, 25 Dec 2020 at 13:32, Max Semenik  wrote:
>>
>>> On Fri, Dec 25, 2020 at 1:21 PM Sebastian Hellmann <
>>> pr-a...@informatik.uni-leipzig.de> wrote:
>>>
 Apologies for cross-posting
>>>
>>>
>>> Apologies not accepted. Don't know about others on this list, but I'm
>>> tired of your spam of conferences very remotely related to MediaWiki
>>> development. MediaWiki is not Semantic MediaWiki, 99% of people here don't
>>> care about your stuff. Please stop.
>>>
>>> --
>>> Best regards,
>>> Max Semenik
>>> ___
>>> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Backport and Config changes window (name change)

[Dan Garry (Deskana)]

On Mon, 8 Jun 2020 at 17:58, Greg Grossmeier  wrote:

> Until today if you wanted to get a backport or config change deployed to
> production you used what was termed the "SWAT" window.
>
> As of today that window of time is now called the "Backport and Config"
> window. This solves a few problems. First, the overly militarized and
> violence-implying name is no longer something we want in our community.
> Second, this now accurately and clearly describes what the purpose of the
> window is.
>

A good change. Thanks!

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

Re: [Wikitech-l] Gerrit outage

[Dan Garry (Deskana)]

On Tue, 19 Mar 2019 at 10:50, Lewis Cawte via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> Not everyone is aware that the process of cleaning up the vandalism/fixing
> Gerrit includes Gerrit being down temporarily.
>
> Do I need to include a reminder link to WP:AGF / WP:DICK?
>

That would not be helpful. By assuming that the other person simply missed
the other thread on this mailing list, and by pointing the person to said
thread, Andre *is* assuming good faith.

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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Dan Garry (Deskana)]

Strainu,

I, too, am glad for the discussion!

On Sat, 9 Mar 2019 at 22:31, Strainu  wrote:

> Let me start with a simple question, to put the references to wmf into
> context. You keep talking below about volunteer developers and how they can
> take over any project.


I'm confused by this. I didn't mention volunteer teams taking over projects
at all, and I don't think that'd work except in very rare and limited
circumstances. I was talking about people helping with bug triage on
Phabricator.


> While that's true, how many fully-volunteer teams
> are there?  How does that number compare to the number of wmf teams? Am I
> right to assume the ratio is hugely in favor of wmf teams?  Note: teams,
> not developers, since decisions on project management are usually done at
> team level.
>

See above; this wasn't what I meant.


> In my experience in b2b contracts they don't keep it a secret, they usually
> have SLAs they respect, but ok, let's leave it at that.
>

Yes, I have more to say about this, but this would be tangential to this
discussion. :-)


> Responsibility for what? Developing and hosting  MediaWiki? Helping
> communities concentrate on creating and attracting content without having
> to work around bugs? I'm sorry, but that's precisely one of the
> responsibilities of the wmf and this is what's discussed here.
>

Well, in your earlier emails in this thread, you mentioned the bug backlog
steadily increasing, so that was what I was talking about. Is that not what
you were talking about in your subsequent emails?


> This is one thing that we agree on: nobody committed on anything. Ever.
> That's why I asked above: what does it take to have someone (anyone) at the
> WMF act upon these discussions?
>
> My role in the Wikimedia tech community is tech ambassador above all else,
> so I'm caught in the middle here: I have to explain new features and
> technical decisions to people who don't care about php, js or server
> performance , but I also feel obligated to relay their requirements, as I
> see them, to the development team. This second process does not happen as
> smoothly as it should.
>
> It's not healthy to ignore discussion after discussion and claim it's a
> community issue. It's not. It's a governance issue and it's growing every
> day.
>

I agree. It's not a community issue, it's a movement-wide one. I don't know
how to solve it.


> The projects belong to the community at large, not just the technical
> subcommunity. They are the ones affected by the  bugs and also they are the
> ones that need our support. So why should they be ignored in taking this
> decision?
>

I'm confused by this too. I wasn't talking about ownership of the Wikimedia
projects, I was again talking about the bug backlog, which anyone is
welcome to get involved in simply by registering an account.


> My proposal is to begin the discussion here: how can we better relay issues
> that are more important to communities than new features? How can we have a
> "community whishlist for bugs"?
>

The community wishlist explicitly accepts requests to fix bugs, as well
requests for new features. So, is what you're asking for some process to
supplement that?

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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Dan Garry (Deskana)]

On Sat, 9 Mar 2019 at 11:26, Strainu  wrote:

> How many successful commercial projects leave customer issues unresolved
> for years because they're working on something else now?
>

Almost all of them, they just keep it secret. Companies pay millions of
dollars each year for support packages, even after having paid for software
in the first place, specifically because otherwise their support issues may
not be answered in a timely fashion, or even answered at all. I don't think
comparing us to commercial products makes much sense in this context.


> There were a
> number of proposals on how to track such issues so that reporters have a
> clear image of the status of the bugs. Have any of them been tried by at
> least one of the teams at wmf? If so, is there a way to share the results
> with other teams? If not, how can we convince the wmf to give them a
> chance?
>

I don't agree with shifting responsibility onto the Wikimedia Foundation.
There's an anti-pattern here: we all have a big mailing list discussion,
agree there's a problem, agree that the Foundation should solve the
problem, then ask again in a year what they did even though they didn't
actually say they'd do anything about it. That's not a healthy dynamic.

The technical space is owned by all of us, so if we, as a technical
community, decide this is important to us, then we can look at the problem
and try to tackle it, and then figure out how the Wikimedia Foundation
could catalyse that.

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

Re: [Wikitech-l] PHP 7 is now a beta feature

[Dan Garry (Deskana)]

Cool! Thanks for developing this beta feature, it makes it easy to test.

Is there anything in particular that you might expect to behave
differently, or break, that you'd like us to test? Are you just looking for
more general feedback?

Thanks!

Dan

On Mon, 28 Jan 2019 at 14:31, Giuseppe Lavagetto 
wrote:

> Hi all,
>
> as some of you might know, HHVM has decided some time ago to drop support
> for PHP, choosing to only support Hack (Facebook's own PHP-derivative
> language)[1].
>
> This forced us to consider alternatives. In particular the last major
> upgrade to PHP, PHP 7, was supposed to have greatly improved the
> performance of the runtime, guaranteeing performance on par with HHVM.
>
> Given that early tests[2] showed promising performance, we decided to work
> on PHP7 support and on its rollout in production.
>
> I'm happy to announce that PHP 7 is now available as a beta feature on all
> wikis, and I encourage everyone to try it out and report bugs using the
> #php7.2-support tag.
>
> After this period of beta testing, we will proceed with a progressive
> rollout to a growing percentage of users, and hopefully we'll complete the
> transition in the next four months.
>
> A huge thank you to all the people who worked hard to reach this goal!
>
> Thanks,
>
> Giuseppe
> [1] https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
> [2]
> https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088854.html
> --
> Giuseppe Lavagetto
> Principal Site Reliability Engineer, 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] [Engineering] Gerrit now automatically adds reviewers

[Dan Garry (Deskana)]

Something new was tried in the hopes it'd be good, it turned out not to be
good, it was reverted, and now there's some discussion about how to make it
better. That's a successful process, not an unsuccessful one.

Given that this exact method of doing things is not only well-established
on the English Wikipedia but is also a recommended pattern (
bold-revert-discuss ), I'm not
sure why you think this would be unacceptable there.

Dan

On Fri, 18 Jan 2019 at 22:13, Pine W  wrote:

> I'm glad that this problematic change to communications was reverted.
>
> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment. Involving TechCom might also be appropriate. It appears that
> none of those happened here. In terms of process this situation looks to me
> like it's inexcusable.
>
> In the English Wikipedia community, doing something like this would have a
> reasonable likelihood of costing an administrator their tools, and I hope
> that a similar degree of accountability is enforced in the engineering
> community. In particular, I expect engineering supervisors to follow
> established technical processes for changes that impact others' workflows,
> and if they decide to skip those processes without a compelling reason
> (such as a site stability problem) then I hope that they will be held
> accountable. Again, from my perspective, the failure to follow process here
> is inexcusable.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> 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] 2019-01-09 Scrum of Scrums meeting notes

[Dan Garry (Deskana)]

On Wed, 9 Jan 2019 at 20:25, Pine W  wrote:

> I would like to request that every Audiences and Technology team submit
> highlights of recent and upcoming activities for inclusion in every set of
> SoS notes, even if no one personally attends the SoS meeting from a
> particular team, so that readers of these notes can keep better track of
> what is happening in the Audiences and Technology departments and so that
> readers can make adjustments to our own plans as needed.


Scrum of scrums meetings are intended to be a venue for development teams
to surface upcoming blockers and dependencies on other teams, so that teams
can better work together and not block each other. Scrum of scrums meetings
are not intended to be a forum for general announcements about activities
by end-users. These are very different use cases with different target
audiences.

I understand your concerns about visibility of the actions inside the
Wikimedia Foundation. It's certainly difficult to see things from the
outside. That said, taking a meeting with a well-defined purpose and
objective, and expanding that objective to add an additional, quite
different use case, is not good practice; doing so may cause people to
disengage or lose focus, thereby meaning the original objective of the
meeting is no longer met.

Some reading you might find useful:

   - https://www.agilealliance.org/glossary/scrum-of-scrums/
   - https://www.scruminc.com/scrum-of-scrums/

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