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

[Pine W]

Stas made a point that I was considering too, although from a different
perspective.

One of the issues may be a difference between end user expectations and
what the resources are available to fulfill those expectations.

Communications requires time and mental bandwidth, both of which are
limited resources for everyone, including WMF staff and end users. Also,
there are financial considerations regarding how people use their time.

From the end user perspective, reporting a bug and then having nothing
happen, or getting an initial reply but later seeing that a bug appears to
stall for months or years, may be frustrating depending on the nature of
the bug and the patience of the user. I think that communicating with users
regarding when bugs will likely be fixed would be helpful. I think that
some of that happens already, but there's more that can be done. There are
probably ways to automate some of these communications to a degree.

On the larger scale, I don't know whether it's possible to get a good large
scale understanding of all of the open tasks in Phabricator. I speculate
that teams might be able to create semi-automated reports regarding their
own teams' tasks. To get a larger view of the situation in Phabricator
might require combining the unique outputs of the reports from individual
teams. By having a big picture view of the situation I hope that we could
improve our collective situational awareness regarding tasks, including
open feature requests and technical debt. Also, by creating snapshots of
the results of the same type of combined report over a period of months or
years, maybe we could get a sense of how technical debt is changing over
time.

To summarize: I am thinking that a two pronged approach would be good, one
regarding communications regarding the status of individual bugs, and one
regarding a big picture analysis of technical debt.

I realize that there would be costs of time and money for both of those
approaches. Automation can help with both.

My guess is that managing thousands of bugs in an continuous development
environment is challenging in the best of circumstances. I am somewhat
familiar with the end user experience and financial considerations (both of
which motivated me to participate in this thread), but I'm not an expert in
software engineering for a product that is on the scale of a top 10 website.

What do others think regarding these proposals?

Thanks for the good discussion.

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

Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

On 14/3/19 1:00 pm, Gergo Tisza wrote:
> On Wed, Mar 13, 2019 at 5:33 PM Tim Starling 
> wrote:
> 
>> File a task in Phabricator under the Gerrit-Privilege-Requests
>> project, recommending that the person be given access, giving your
>> reasons and mentioning that you are the maintainer of the project in
>> question. Wait for at least a week for comments. Then a Gerrit
>> administrator should add the person and close the task.
>>
> 
> Does the policy apply to Toolforge tools at all? The current text says "For
> extensions (and other projects) not deployed to the Wikimedia cluster, the
> code review policy is up to the maintainer or author of the extension." I'd
> assume that by extension managing +2 permissions is also up to them
> (although this is not explicitly stated, might be worth clarifying).

No, managing +2 permissions is not up to the maintainer of the tool,
that's the whole point of the change.

-- Tim Starling

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

Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

On 16/3/19 7:53 am, Andre Klapper wrote:
> On Wed, 2019-03-13 at 15:24 +1100, Tim Starling wrote:
>> * The Phabricator projects for requesting access have changed. I'm in
>> the process of moving the tickets over.
> 
> What is supposed to happen with
> https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?
> 
> Do you plan to archive that project as it's superseded by
> https://phabricator.wikimedia.org/tag/mediawiki-gerrit-group-requests/
> and https://phabricator.wikimedia.org/tag/gerrit-privilege-requests/ ?

I archived it.

-- Tim Starling


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

Re: [Wikitech-l] Thank you Tuesday

[Stas Malyshev]

Hi!

> Any day can be Tuesday if you really want.

Thanks to Antoine and Brad for figuring the hhvm crash in
https://phabricator.wikimedia.org/T216689. Finding the cause of random
crashes can be very hard and frustrating, but they figured it out and
resolved it quickly. Thanks!

-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikitech-l] New Gerrit privilege policy

[Andre Klapper]

On Wed, 2019-03-13 at 15:24 +1100, Tim Starling wrote:
> * The Phabricator projects for requesting access have changed. I'm in
> the process of moving the tickets over.

What is supposed to happen with
https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?

Do you plan to archive that project as it's superseded by
https://phabricator.wikimedia.org/tag/mediawiki-gerrit-group-requests/
and https://phabricator.wikimedia.org/tag/gerrit-privilege-requests/ ?

andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



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

[Wikitech-l] TechCom Radar 2019-03-13

[Kate Chapman]

Hi All,

Here are the minutes from this week's TechCom meeting:

* IRC Meeting Scheduled: RFC: Add a frontend build step to
skins/extensions to our deploy process
 March 20 2pm PST (21:00
UTC, 22:00 CET) in #wikimedia-office

* IRC Meeting Scheduled: RFC: Let's stop using QUnit as a mechanism
for integration tests 
March 20 2:45pm PST (21:45 UTC, 21:45 CET) in #wikimedia-office

* Last Call extended by one week: RfC: Standards for external services
in the Wikimedia infrastructure.
 ending March 20 1pm PST
(March 20 20:00 UTC, 21:00 CET)

* Last Call: The Great Namespaceization and Reorg
 ending March 20 1pm PST
(20:00 UTC, 21:00 CET)

* Under discussion: Remove .m. subdomain, serve mobile and desktop
variants through the same URL


* Under discussion: RFC: Skin https://phabricator.wikimedia.org/T217158>

* No IRC meeting this week

You can also find our meeting minutes at


See also the TechCom RFC board
.

If you prefer you can subscribe to our newsletter here


Thanks,
Kate

--
Kate Chapman
Senior Program Manager, Core Platform
Wikimedia Foundation
kchap...@wikimedia.org

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

[Wikitech-l] Thank you Tuesday

[Bartosz Dziewoński]

Any day can be Tuesday if you really want.

* Thanks to Strainu for insightful comments on the "Backlog on bugs" thread.

* Thanks to Roan and Ed for stepping up to review major OOUI patches 
this week (and to Moriel, Cormac and Matthias who proposed said patches).


--
Bartosz Dziewoński

___
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

[Strainu]

În joi, 14 mar. 2019 la 22:23, Gergő Tisza  a scris:
> About backlogs in general, Chromium is probably the biggest
> open-source Google repo; that has currently 940K tickets, 60K of which are
> open, and another 50K have been auto-archived after a year of inactivity.
> (As others have pointed out, having a huge backlog and ruthlessly closing
> tasks that do not get on the roadmap are the only two realistic options,
> and the latter does have its advantages, no one here seems to be in favor
> of it.) We have 220K tasks in total, 40K of which are open, so that's in
> the same ballpark

That's an overstatement: 18% (not counting bugs closed as declined) is
almost double to 11%. If you're going this route, we're doing much
worse than Chromium.

>
> On Wed, Mar 13, 2019 at 3:02 PM Strainu  wrote:
>
> > The main problem I see with the community wishlist is that it's a
> > process beside the normal process, not part of it. The dedicated team
> > takes 10 bugs and other developers another ~10. I think we would be
> > much better off if each team at the WMF would also take the top ranked
> > bug on their turf and solve it and bump the priority of all the other
> > bugs by one (e.g. low->medium). One bug per year per team means at
> > least 18 bugs (at least if [1] is up to date) or something similar.
> >
>
> Community Tech is seven people and they do ten wishlist requests a year.
> (Granted, they do other things too, but the wishlist is their main focus.)
> So you are proposing to reallocate on average 1-2 months per year for every
> team to work on wishlist wishes. That's about two million dollars of donor
> money. How confident are you that the wishlist is actually a good way of
> estimating the impact of tasks, outside of the narrow field where editors
> have personal experience (ie. editing tools)?

I'm 99.9% sure the wishlist is relevant in at least half the
categories (Admins, Bots, Editing, Notifications,
Programs, Watchlists, Wikidata, Wikisource, Wiktionary) and
very likely (80%) also for Anti-harassment, Categories and Maps.

I'm not sure how you arrived at the $2M figure (even 36 months of dev
time - 18 teams, 2 man-months/team - only add up to ~$400K, unless
Glasdoor is waaay off on the salaries there [2]), but presumably going
down on the list will also surface bugs and not only features, which
will take less time to solve. Investing an additional 1% of the
revenue into this seems reasonable to me.

[2] https://www.glassdoor.com/Salary/Wikimedia-Foundation-Salaries-E38331.htm

>
> UploadWizard is not in active development currently.

I did not claim (or asked) that it was. What I said is that it is an
important part of the infrastructure and that it should be maintained
properly. I also said I will try to come up with a more detailed
critique later on and see if it has any result.

Strainu

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

Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist

[Željko Filipin]

Hi everybody,

I'm in charge of train this week. Should this be added as a blocker?

https://phabricator.wikimedia.org/T206675

Thank you,

Željko

On Thu, Mar 14, 2019 at 6:37 PM Roan Kattouw  wrote:

> This sounds like it could have been caused by
> https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198
>
> ‪On Thu, Mar 14, 2019 at 10:29 AM ‫יגאל חיטרון‬‎ 
> wrote:‬
>
> > Hello. There is a regression problem, that started on this week
> deployment.
> > I can see it in group 1 from yesterday evening. I do not file a
> phabricator
> > ticket, because there is no algorithm to reproduce the problem.
> >
> > From time to time the API post query "mark this revision as read" does
> not
> > work. In these times, there is a reproducing algorithm:
> > 1) Open Special:Watchlist.
> > 2) Pick an unread revision.
> > 3) Open the diff to last version, or the view mode of the page.
> > 4) Expected: the revision, and the whole page, should be automatically
> > marked as read.
> > 5) Refresh the Special:Watchlist.
> > 6) Got: the revision remains bold.
> > 7) Open API query for unread revisions, the relevant one is still there.
> > 8) Try partagraphs 5-7 every 5 seconds.
> > 9) In about twenty minutes the data is updated correctly.
> > I saw this yesterday at about 19:45 UTC, and it happens again just now.
> > Thank you.
> > Igal (User:IKhitron)
> > ___
> > 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] Fwd: MathML Refresh

[Physikerwelt]

Hi all,

just for your information: An update about the upcoming improvement in
the MathML implementation in Firefox and the new implementation in
Chromium.

Best
physikerwelt


-- Forwarded message -
From: Frédéric Wang 
Date: Fri, Mar 15, 2019 at 11:35 AM
Subject: MathML Refresh Heads up
To: 


Hello Mozilla developers,

As some of you may know, Igalia is working on MathML support in Chromium
this year [1]. As part of that effort we joined a new MathML Refresh
Community Group [2] and one goal is to focus on a core spec for browser
implementations [3] to:
- Remove deprecated/uncommon/duplicate math features that could be
implemented by polyfills (relying on MathML core and other web
technologies).
- Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
help implementation and conformance testing.
- Align MathML with CSS/HTML (parsing, layout...), introducing new web
platform features (CSS, fonts...) for math if necessary.

We expect that this effort will improve browser interoperability and
reduce complexity of current implementations.

This is just a heads up to say that some work is likely to happen to
update/remove/add MathML features. The appropriate "Intents" will be
sent later to these mailing lists.

Frédéric and Rob,

[1] https://mathml.igalia.com/
[2] https://mathml-refresh.github.io/
[3] https://mathml-refresh.github.io/mathml-core/

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