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

[Andre Klapper]

Hi and thanks for joining the discussion!

On Sat, 2019-03-16 at 20:37 -0400, Thomas Eugene Bishop wrote:
> Here’s a specific example, created in 2015:
> 
>   https://phabricator.wikimedia.org/T116145 <
> https://phabricator.wikimedia.org/T116145>
> 
> 
> A bug fix was provided years ago but never accepted or rejected. It’s
> the first and last MediaWiki bug ever assigned to me. I’ve just
> unassigned myself.
> 
> In cases like this, remarks like “Because you did not fix these bugs”
> and “... anyone is free to pick it up and work on it ... No further
> response needed” miss the point. When a bug fix is provided, but
> nobody with authority to accept or reject it ever does so, that’s a
> failure on the part of those who have authority, not on the part of
> those who are able and willing to fix bugs. Sure, volunteers are
> “free” to waste their time!
> 
> You need to use and share your authority more effectively, to “be
> bold” with accepting and rejecting bug fixes. Authorize more people
> to accept or reject bug fixes. Assign each proposed bug fix to one
> such person, starting with the oldest bugs. Then hold those people
> accountable. You don’t lack volunteers, you lack volunteers with
> authority.

I fully agree. I was referring to bug reports in my emails.

Code review is an area in which Wikimedia is very frustrating. There
are regular emails about patches by new contributors awaiting review
[1] but that obviously only covers a small group of contributors.
And while we recently started to have code stewardship reviews [2] to
fill some gaps in the list of responsible persons and teams [3] per
code base, we for example still lack meaningful statistics how big the
code review problem is, in general and per team.

andre

[1] https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091632.html
[2] https://www.mediawiki.org/wiki/Code_stewardship_reviews
[3] https://www.mediawiki.org/wiki/Developers/Maintainers
-- 
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

Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

On 17/3/19 12:48 am, Merlijn van Deen (valhallasw) wrote:
> On Sat, 16 Mar 2019 at 03:01, Tim Starling  wrote:
> 
>> No, managing +2 permissions is not up to the maintainer of the tool,
>> that's the whole point of the change.
>>
> 
> I feel that this policy, although well-meaning, and a step forwards for
> MediaWiki and other WMF-production software, is unreasonably being applied
> as a 'one-size-fits-all' solution to situations where it doesn't make sense.
> 
> Two examples where the policy does not fit the Toolforge situation:
> 
> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
> privileges. For a Toolforge tool, self +2-ing is common and expected: the
> repository is hosted on Gerrit to allow for CI and to make contributions
> from others easier, not necessarily for the code review features.

Merging your own code without review is grounds for revocation, with
several exceptions. One of the exceptions is for code that's not
deployed to the Wikimedia cluster. A toolforge tool would fall under
that exception.

In general, if self-merging is normal policy in some repository, we
are not trying to change that here. The +2 policy section is mostly
copied from the previous policy and is meant to be descriptive of the
current situation.

> 2. Giving someone +2 access to a repository now needs to pass through an
> extended process with checks and balances. At the same time, I can *directly
> and immediately give someone deployment access to the tool.*
> 
> Effectively, this policy forces me to move any tool repositories off Gerrit
> and onto GitHub: time and effort better spent otherwise.

The reason we wanted to make this change is because we didn't want to
repeat GitHub's mistakes. This case of a malware being added to an NPM
package used by many people was fresh in our minds:

https://github.com/dominictarr/event-stream/issues/115

The original maintainer had stopped caring about this package some
time before the incident. He gave contributor access to the first
person who asked, without any sort of check. Even after the malware
was discovered, the original maintainer was dismissive, leaving it for
others to clean up.

We've had an incident on Gerrit of a known malicious user, a Wikipedia
vandal, submitting code with a security vulnerability, using a
previously unknown pseudonym. We don't really want such a person to be
summarily given +2 access to a repository.

I don't think it's a huge inconvenience to list your proposed
contributors on a Phabricator ticket and then to wait a week.

-- Tim Starling


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

Re: [Wikitech-l] Gerrit outage

[Paladox via Wikitech-l]

 The watchlist should be in All-Users. If someone removed your watchlist you 
can clone that repo. Then in .git/config change refs/heads to just refs/*. Then 
it should show some refs (I forget which one you check out so you should try 
them all) you can use git log to see if someone git committed the removal.  
___
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

[Thomas Eugene Bishop]

> On Mar 13, 2019, at 6:48 PM, Andre Klapper  > wrote:
> 
> On Wed, 2019-03-13 at 21:01 +0100, John Erling Blad wrote:
>> ... But nobody does anything about the
>> sinkhole itself.
> 
> And repeating the same thing over and over again while repeatedly
> ignoring requests to be more specific won't help either...

Here’s a specific example, created in 2015:

https://phabricator.wikimedia.org/T116145 



A bug fix was provided years ago but never accepted or rejected. It’s the first 
and last MediaWiki bug ever assigned to me. I’ve just unassigned myself.

In cases like this, remarks like “Because you did not fix these bugs” and “... 
anyone is free to pick it up and work on it ... No further response needed” 
miss the point. When a bug fix is provided, but nobody with authority to accept 
or reject it ever does so, that’s a failure on the part of those who have 
authority, not on the part of those who are able and willing to fix bugs. Sure, 
volunteers are “free” to waste their time!

You need to use and share your authority more effectively, to “be bold” with 
accepting and rejecting bug fixes. Authorize more people to accept or reject 
bug fixes. Assign each proposed bug fix to one such person, starting with the 
oldest bugs. Then hold those people accountable. You don’t lack volunteers, you 
lack volunteers with authority.

Best wishes,

Tom

Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wen...@wenlin.com  Web: 
http://www.wenlin.com 
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯

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

[Wikitech-l] Where should extension default preferences be specified?

[Thomas Eugene Bishop]

There are two places the default value for an extension-specific preference can 
be specified:

(1) DefaultUserOptions in extension.json

(2) onGetPreferences (or whatever function hooks GetPreferences) in 
MyExtension.hooks.php

Which is better?

If you do it in both places, and the defaults are in conflict, evidently 
onGetPreferences wins. This can be seen as follows:

In extension.json add

"DefaultUserOptions": { 
"BeSilly": false
}

In onGetPreferences add

$preferences['BeSilly'] = array(
'type' => 'toggle',
'label' => 'Be silly',
'section' => "$sillySection",
'default' => true
);

The result is that the checkbox is checked by default. If you omit the default 
from extension.json and include it only in onGetPreferences, the result is the 
same.

It seems that using onGetPreferences is preferable, since the default can be 
combined there (encapsulated) with the other information about the preference, 
while putting the default in DefaultUserOptions separates it from the related 
information, a dependency to be avoided unless there’s some advantage I’m 
missing. Putting it in both places is at best redundant.

However, the documentation in 
https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences appears to recommend 
$wgDefaultUserOptions or DefaultUserOptions. While it shows one example of 
specifying 'default' in onGetPreferences, it also shows an example in which 
'default' is not specified in onGetPreferences. So what’s best? I don’t want to 
use onGetPreferences for the default if a future version of MediaWiki is going 
to turn that into a mistake. Also, does DefaultUserOptions serve any purpose, 
if onGetPreferences accomplishes the same thing better?

Thanks in advance for any advice or clarification.

Tom

Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯


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

Re: [Wikitech-l] Gerrit outage

[MGChecker]

Hello,

after the Gerrit outage, my list of watched changes is seemingly empty, while 
it has not been a day before. Is it possible to fix this issue?

MGChecker

-Ursprüngliche Nachricht-
Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von 
Pine W
Gesendet: Samstag, 16. März 2019 21:14
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Gerrit outage

Thanks for the updates and for everyone who was or is working on a weekend day. 
Sometime in the next few weeks if you can publish an incident report that has 
any sensitive information redacted, I would like to read it.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )




On Sat, Mar 16, 2019, 12:25 PM John Bennett  wrote:

> Hello,
>
> Gerrit is available again but we are continuing to investigate the 
> suspicious activity.  Our preliminary findings point to no users or 
> production systems being compromised and no loss of any confidential 
> information. As we continue to investigate over the next few days we 
> will add any appropriate updates to the phabricator task (
> https://phabricator.wikimedia.org/T218472 ) .
>
> Thanks
>
>
> On Sat, Mar 16, 2019 at 10:26 AM John Bennett 
> wrote:
>
> > Hello,
> >
> >
> > On 16 March 2019, Wikimedia Foundation staff observed suspicious 
> > activity associated with Gerrit and as a precautionary step has 
> > taken Gerrit
> offline
> > pending investigation.
> >
> >
> > The Wikimedia Foundation's Security, Site Reliability Engineering 
> > and Release Engineering teams are investigating this incident as 
> > well as potential improvements to prevent future incidents. More 
> > information will be posted on Phabricator 
> > (https://phabricator.wikimedia.org/T218472 ) as it becomes available 
> > and is confirmed. If you have any questions, please contact the 
> > Security (secur...@wikimedia.org ).
> >
> >
> > Thanks
> >
> ___
> 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] Unbreak now! problem in this week train Watchlist

[יגאל חיטרון]

It happens again now.
Igal


בתאריך יום ו׳, 15 במרץ 2019, 15:45, מאת Željko Filipin ‏<
zfili...@wikimedia.org>:

> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Amir Sarabadani]

I just want to point out that this wasn't "handed down by a CTO", it was a
RFC [1] that and was open for discussion to everyone and was discussed
extensively (and the RFC changed because of these discussions, look at the
history of the page), then had an IRC meeting that was also open to
everyone, then had a "last call" period for raising any objections which
was open to everyone too. That passed with no objection being raised and
then it also got approved by the CTO.

I might be wrong, but if I understand the structure of TechCom correctly
(correct me if I'm wrong), it's open and transparent, the CTO can veto
changes (which hasn't happened so far), but it's not like a CTO would just
implement a new policy without discussion. This process is more open and
transparent than most companies and non-profits.

[1]: https://phabricator.wikimedia.org/T216295
Best

On Sat, Mar 16, 2019 at 9:22 PM Yuri Astrakhan 
wrote:

> I agree that while possibly made with good intentions, policy changes like
> these should go through dev community discussion + vote, not be handed down
> from a CTO.  Wikipedia as a movement started that way, and many people
> participated in it because of its transparency and community-driven
> process. Just because now there is a large split between "community" and
> "WMF staff who gets +2 automatically", we should try to keep the original
> values.
>
> On Sat, Mar 16, 2019 at 3:33 PM Zppix  wrote:
>
> > Andre, from what im gathering from this thread thats not what I
> > understand, so i redact the part of my last email about toolforge,
> however
> > my point on this policy change should of been put to a community
> > vote/consensus is valid.
> >
> > --
> > Devin “Zppix” CCENT
> > Volunteer Wikimedia Developer
> > Africa Wikimedia Developers Member and Mentor
> > Volunteer Mozilla Support Team Member (SUMO)
> > Quora.com Partner Program Member
> > enwp.org/User:Zppix
> > **Note: I do not work for Wikimedia Foundation, or any of its chapters. I
> > also do not work for Mozilla, or any of its projects. **
> >
> > > On Mar 16, 2019, at 1:13 PM, Andre Klapper 
> > wrote:
> > >
> > >> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> > >> So your basically telling me, I can’t decide who gets the power to +2
> > >> on for example a toolforge tool I actively am the primary maintainer
> > >> of? Instead it has to be requested. I do not disagree with a lot of
> > >> the changes to technical policies, but with this change it seems to
> > >> restrict ability to scale projects. I also do believe that this
> > >> change should of be taken under RfC or some sort of consensus-gaining
> > >> measure.  I respect the intentions, but I absolutely think the change
> > >> needs reverted then voted on by the technical community.
> > >
> > > Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
> > >
> > > It 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."
> > >
> > > 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 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



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

Re: [Wikitech-l] New Gerrit privilege policy

[Yuri Astrakhan]

I agree that while possibly made with good intentions, policy changes like
these should go through dev community discussion + vote, not be handed down
from a CTO.  Wikipedia as a movement started that way, and many people
participated in it because of its transparency and community-driven
process. Just because now there is a large split between "community" and
"WMF staff who gets +2 automatically", we should try to keep the original
values.

On Sat, Mar 16, 2019 at 3:33 PM Zppix  wrote:

> Andre, from what im gathering from this thread thats not what I
> understand, so i redact the part of my last email about toolforge, however
> my point on this policy change should of been put to a community
> vote/consensus is valid.
>
> --
> Devin “Zppix” CCENT
> Volunteer Wikimedia Developer
> Africa Wikimedia Developers Member and Mentor
> Volunteer Mozilla Support Team Member (SUMO)
> Quora.com Partner Program Member
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters. I
> also do not work for Mozilla, or any of its projects. **
>
> > On Mar 16, 2019, at 1:13 PM, Andre Klapper 
> wrote:
> >
> >> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> >> So your basically telling me, I can’t decide who gets the power to +2
> >> on for example a toolforge tool I actively am the primary maintainer
> >> of? Instead it has to be requested. I do not disagree with a lot of
> >> the changes to technical policies, but with this change it seems to
> >> restrict ability to scale projects. I also do believe that this
> >> change should of be taken under RfC or some sort of consensus-gaining
> >> measure.  I respect the intentions, but I absolutely think the change
> >> needs reverted then voted on by the technical community.
> >
> > Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
> >
> > It 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."
> >
> > 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 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] Gerrit outage

[Pine W]

Thanks for the updates and for everyone who was or is working on a weekend
day. Sometime in the next few weeks if you can publish an incident report
that has any sensitive information redacted, I would like to read it.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )




On Sat, Mar 16, 2019, 12:25 PM John Bennett  wrote:

> Hello,
>
> Gerrit is available again but we are continuing to investigate the
> suspicious activity.  Our preliminary findings point to no users or
> production systems being compromised and no loss of any confidential
> information. As we continue to investigate over the next few days we will
> add any appropriate updates to the phabricator task (
> https://phabricator.wikimedia.org/T218472 ) .
>
> Thanks
>
>
> On Sat, Mar 16, 2019 at 10:26 AM John Bennett 
> wrote:
>
> > Hello,
> >
> >
> > On 16 March 2019, Wikimedia Foundation staff observed suspicious activity
> > associated with Gerrit and as a precautionary step has taken Gerrit
> offline
> > pending investigation.
> >
> >
> > The Wikimedia Foundation's Security, Site Reliability Engineering and
> > Release Engineering teams are investigating this incident as well as
> > potential improvements to prevent future incidents. More information will
> > be posted on Phabricator (https://phabricator.wikimedia.org/T218472 ) as
> > it becomes available and is confirmed. If you have any questions, please
> > contact the Security (secur...@wikimedia.org
> > ).
> >
> >
> > Thanks
> >
> ___
> 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] New Gerrit privilege policy

[Zppix]

Andre, from what im gathering from this thread thats not what I understand, so 
i redact the part of my last email about toolforge, however my point on this 
policy change should of been put to a community vote/consensus is valid.

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also 
do not work for Mozilla, or any of its projects. ** 

> On Mar 16, 2019, at 1:13 PM, Andre Klapper  wrote:
> 
>> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
>> So your basically telling me, I can’t decide who gets the power to +2
>> on for example a toolforge tool I actively am the primary maintainer
>> of? Instead it has to be requested. I do not disagree with a lot of
>> the changes to technical policies, but with this change it seems to
>> restrict ability to scale projects. I also do believe that this
>> change should of be taken under RfC or some sort of consensus-gaining 
>> measure.  I respect the intentions, but I absolutely think the change
>> needs reverted then voted on by the technical community. 
> 
> Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
> 
> It 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."
> 
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit outage

[John Bennett]

Hello,

Gerrit is available again but we are continuing to investigate the
suspicious activity.  Our preliminary findings point to no users or
production systems being compromised and no loss of any confidential
information. As we continue to investigate over the next few days we will
add any appropriate updates to the phabricator task (
https://phabricator.wikimedia.org/T218472 ) .

Thanks


On Sat, Mar 16, 2019 at 10:26 AM John Bennett 
wrote:

> Hello,
>
>
> On 16 March 2019, Wikimedia Foundation staff observed suspicious activity
> associated with Gerrit and as a precautionary step has taken Gerrit offline
> pending investigation.
>
>
> The Wikimedia Foundation's Security, Site Reliability Engineering and
> Release Engineering teams are investigating this incident as well as
> potential improvements to prevent future incidents. More information will
> be posted on Phabricator (https://phabricator.wikimedia.org/T218472 ) as
> it becomes available and is confirmed. If you have any questions, please
> contact the Security (secur...@wikimedia.org
> ).
>
>
> Thanks
>
___
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 Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> So your basically telling me, I can’t decide who gets the power to +2
> on for example a toolforge tool I actively am the primary maintainer
> of? Instead it has to be requested. I do not disagree with a lot of
> the changes to technical policies, but with this change it seems to
> restrict ability to scale projects. I also do believe that this
> change should of be taken under RfC or some sort of consensus-gaining 
> measure.  I respect the intentions, but I absolutely think the change
> needs reverted then voted on by the technical community. 

Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?

It 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."

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

Re: [Wikitech-l] New Gerrit privilege policy

[Zppix]

So your basically telling me, I can’t decide who gets the power to +2 on for 
example a toolforge tool I actively am the primary maintainer of? Instead it 
has to be requested. I do not disagree with a lot of the changes to technical 
policies, but with this change it seems to restrict ability to scale projects. 
I also do believe that this change should of be taken under RfC or some sort of 
consensus-gaining measure.  I respect the intentions, but I absolutely think 
the change needs reverted then voted on by the technical community. 

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also 
do not work for Mozilla, or any of its projects. ** 

> On Mar 16, 2019, at 9:57 AM, Isarra Yos  wrote:
> 
>> On 16/03/2019 14:35, Bartosz Dziewoński wrote:
>>> On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
>>> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
>>> privileges. For a Toolforge tool, self +2-ing is common and expected: the
>>> repository is hosted on Gerrit to allow for CI and to make contributions
>>> from others easier, not necessarily for the code review features.
>> 
>> The policy calls out this case as acceptable:
>> 
>> "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. 
>> Some non-Wikimedia extensions follow Wikimedia's policy of prohibiting 
>> self-merges, but there is no requirement of that. If you are the only person 
>> writing the extension and have nobody to review your change, or if the 
>> extension is abandoned, it is acceptable to self-merge your changes."
>> 
> The problem is now it's a lot more difficult to start scaling beyond that. 
> Perhaps we simply need an exception for this, too, in these cases?
> 
> -I
> 
> 
> ___
> 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] Gerrit outage

[John Bennett]

Hello,


On 16 March 2019, Wikimedia Foundation staff observed suspicious activity
associated with Gerrit and as a precautionary step has taken Gerrit offline
pending investigation.


The Wikimedia Foundation's Security, Site Reliability Engineering and
Release Engineering teams are investigating this incident as well as
potential improvements to prevent future incidents. More information will
be posted on Phabricator (https://phabricator.wikimedia.org/T218472 ) as it
becomes available and is confirmed. If you have any questions, please
contact the Security (secur...@wikimedia.org 
).


Thanks
___
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 sâm., 16 mar. 2019 la 15:55, David Barratt  a scris:
>
> Perhaps a better example would be the Drupal community who has a total of
> ~1,071,600 issues and ~282,350 of those are open
> https://www.drupal.org/project/issues and they have several organizations
> https://www.drupal.org/organizations working on the software.

Maybe, maybe not - I'm not familiar with Drupal development, but
precisely because of the fragmented contributions, chances are some
bugs fall between teams. As discussed previously in the thread, MW
development is much more centralized, so better coordination is to be
expected.

That being said, their org stats are pretty awsome, is there any way
to obtain similar stats from Phabricator/Gerrit (at least by email
domain if nothing else)?

>
> I do not understand how a large backlog is a problem. It is not an
> indication of anything.

A large backlog by itself is not alarming. A growing one for
components deployed to WMF sites is. It indicates insufficient
attention is given to ongoing maintenance of projects after they are
no longer "actively developed", which in turn creates resentment with
the reporters.

I've checked the burnup graphs Andre referred to for some of the
extensions with high editor visibility (UW, VE, CX) and they all have
a similar pattern - huge increase in the first ~12 months after being
widely deployed, then a much reduced, but visible, growing rate, with
some sharp decreases which correspond to a peak in activity (new team
culling the backlog? volunteer developer solving a few bugs?). I tried
to compare that with the overall pattern, but Phabricator timed out -
if somebody could obtain and publish the overall burnup rate data
somewhere, that would be great.

I guess the question is what's an acceptable backlog growing rate (key
secondary question: for who?) and if it is different between projects.
I don't know how to respond to that.

> On Fri, Mar 15, 2019 at 12:25 PM Strainu  wrote:
>
> > Î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 

Re: [Wikitech-l] New Gerrit privilege policy

[Isarra Yos]

On 16/03/2019 14:35, Bartosz Dziewoński wrote:

On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
1. According to the policy, self-+2'ing is grounds for revocation of 
Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: 
the

repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.


The policy calls out this case as acceptable:

"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. Some non-Wikimedia extensions follow Wikimedia's policy 
of prohibiting self-merges, but there is no requirement of that. If 
you are the only person writing the extension and have nobody to 
review your change, or if the extension is abandoned, it is acceptable 
to self-merge your changes."


The problem is now it's a lot more difficult to start scaling beyond 
that. Perhaps we simply need an exception for this, too, in these cases?


-I


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

Re: [Wikitech-l] New Gerrit privilege policy

[Bartosz Dziewoński]

On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.


The policy calls out this case as acceptable:

"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. Some non-Wikimedia extensions follow Wikimedia's policy of 
prohibiting self-merges, but there is no requirement of that. If you are 
the only person writing the extension and have nobody to review your 
change, or if the extension is abandoned, it is acceptable to self-merge 
your changes."


--
Bartosz Dziewoński

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

Re: [Wikitech-l] New Gerrit privilege policy

[Isarra Yos]

On 16/03/2019 13:48, Merlijn van Deen (valhallasw) wrote:

On Sat, 16 Mar 2019 at 03:01, Tim Starling  wrote:


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


I feel that this policy, although well-meaning, and a step forwards for
MediaWiki and other WMF-production software, is unreasonably being applied
as a 'one-size-fits-all' solution to situations where it doesn't make sense.

Two examples where the policy does not fit the Toolforge situation:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.

2. Giving someone +2 access to a repository now needs to pass through an
extended process with checks and balances. At the same time, I can *directly
and immediately give someone deployment access to the tool.*

Effectively, this policy forces me to move any tool repositories off Gerrit
and onto GitHub: time and effort better spent otherwise.


Similar issues for smaller skins and extensions. Even in those cases 
where it doesn't merit a move, we'll probably just wind up self-merging 
even more than we already do, and putting even more of the burden of any 
actual review on the folks with +2 higher up, because that's just easier.


-I


___
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

[David Barratt]

Perhaps a better example would be the Drupal community who has a total of
~1,071,600 issues and ~282,350 of those are open
https://www.drupal.org/project/issues and they have several organizations
https://www.drupal.org/organizations working on the software.

I do not understand how a large backlog is a problem. It is not an
indication of anything.


On Fri, Mar 15, 2019 at 12:25 PM Strainu  wrote:

> Î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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Merlijn van Deen (valhallasw)]

On Sat, 16 Mar 2019 at 03:01, Tim Starling  wrote:

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

I feel that this policy, although well-meaning, and a step forwards for
MediaWiki and other WMF-production software, is unreasonably being applied
as a 'one-size-fits-all' solution to situations where it doesn't make sense.

Two examples where the policy does not fit the Toolforge situation:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.

2. Giving someone +2 access to a repository now needs to pass through an
extended process with checks and balances. At the same time, I can *directly
and immediately give someone deployment access to the tool.*

Effectively, this policy forces me to move any tool repositories off Gerrit
and onto GitHub: time and effort better spent otherwise.

Merlijn
___
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 Sat, 2019-03-16 at 12:59 +1100, Tim Starling wrote:
> On 16/3/19 7:53 am, Andre Klapper wrote:
> > What is supposed to happen with
> > https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?
> 
> I archived it.

Thanks! I've updated its Phab project description to explain where to
go instead now, in case there are lingering links out there.

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

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

[Andre Klapper]

On Sat, 2019-03-16 at 04:52 +, Pine W wrote:
> 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. 

What does "understanding" imply; which understanding do you lack? It's
hard to help understand without knowing what's specifically missing. :)

> I speculate that teams might be able to create semi-automated reports
> regarding their own teams' tasks. 

Which specific problem do you think would be improved by reports?

Not sure if it's what you're after: There are Burndown charts. Example:
https://phabricator.wikimedia.org/maniphest/report/burn/?project=PHID-PROJ-kfrrtvyn66ou2iq4y4ai
or in Phlogiston. For more information, see
https://www.mediawiki.org/wiki/Phabricator/Project_management#Scrum_in_Phabricator

> To get a larger view of the situation in Phabricator might require
> combining the unique outputs of the reports from individual teams. 

Can you explain why a "larger view" would solve a problem and which
problem that is? It's probably not 'some bugs will never get fixed'.
Maybe it's 'some tickets don't get a reply'. Maybe it is 'some tickets
should get prioritized differently'. Or maybe something else.
These are different things...

> 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.

For the records, that would require excluding feature requests from any
statistics. Plus definitions and understanding of tech debt differ.
Plus tech debt can also be "TODO" code comments and many other things.

> To summarize: I am thinking that a two pronged approach would be good, one
> regarding communications regarding the status of individual bugs

If something happens on an individual ticket, someone communicates that
in that ticket. Examples: People move some tasks on workboards, people
assign some tasks, people add some comments. What exactly is missing?
Do you have an example that's not abstract high-level, please? :)

> 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.

It's still unclear to me which actual underlying problem(s) you'd like
to get solved. The message seems to mix several things ('no reply to
some tasks', 'some tasks might get replies but not fixed', 'some tasks
should be prioritized differently' etc) but maybe I misunderstand.

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