Re: [Wikitech-l]  Wikimedia production errors help

[Ed Sanders]

Speaking specifically about the new JavaScript error logging, and
specifically to Alex's point about triaging these tasks, it would be very
helpful if the reports included some indication of how often the error is
occurring.

For example, VisualEditor is loaded several hundred thousands times per
day. If an error has occurred 4 times in the last 30 days (based on a
recent example) then it is probably very low priority.

On Thu, 17 Sep 2020 at 16:40, C. Scott Ananian 
wrote:

> ACN -- for what it's worth, I've been working for the foundation for a
> while now, and I can report from the inside that the trend is definitely in
> a positive direction.  There is a lot more internal focus on addressing
> code debt and giving maintenance a fair spot at the table.  (In fact, my
> entire team is now sitting inside 'maintenance' now, apparently; we used to
> be 'platform evolution'.)  This email thread is one visible aspect of that
> focus on code quality, not just features.
>
> That said, the one aspect which hasn't improved much in my time at the
> foundation has been the tendency of teams to work in silos.  This thread
> also seems to be a symptom of that: a bunch of production issues are being
> dropped on the floor ('not resolved in over a month') because they are
> falling between the silos and nobody knows who is best able to fix them.
> There are knowledge/expertise gaps among the silos as well: someone
> qualified to fix a DB issue might be at sea trying to track down a front
> end bug, and vice-versa---a number of generalists in the org could
> technically tackle a bug no matter where it lies, but it will take them
> much longer to grok an unfamiliar codebase than it would for someone more
> familiar with that silo.  So bug triage is an increasingly technical task
> in its own right.
>
> This thread, as I read it sitting inside the org, isn't so much asking for
> more attention to be paid to maintenance -- we're winning that battle,
> internally -- as it is a plea for those folks on the edges of their silos
> to keep an eye out for these things which are currently falling between
> them and help with the triage.
>   --scott, speaking only for myself and my view here
>
>
>
> On Wed, Sep 16, 2020 at 11:25 PM AntiCompositeNumber <
> anticompositenum...@gmail.com> wrote:
>
> > There is an impression among many community members, myself included,
> > that Foundation development generally prioritizes new features over
> > fixing existing problems. Foundation teams will sprint for a few
> > months to put together a minimum viable product, release it, then move
> > on to the new hotness, leaving user requests, bugfixes, and the like
> > behind. It often seems that the only way to get a bug fixed is to get
> > a volunteer developer to look at it. This is likely unintentional, but
> > it happens nonetheless.
> >
> > Putting a higher priority within the Foundation on cleaning up old
> > toys before taking out new ones is necessary for the long-term
> > stability of the projects.
> >
> > ACN
> >
> > On Wed, Sep 16, 2020 at 9:05 PM Dan Andreescu 
> > wrote:
> > >
> > > >
> > > > For example, of the 30 odd backend errors reported in June, 14 were
> > still
> > > > open a month later in July [1], and 12 were still open – three months
> > later
> > > > – in September. The majority of these haven't even yet been triaged,
> > > > assigned assigned or otherwise acknowledged. And meanwhile we've got
> > more
> > > > (non-JavaScript) stuff from July, August and September adding
> > pressure. We
> > > > have to do better.
> > > >
> > > > -- Timo
> > > >
> > >
> > > This feels like it needs some higher level coordination.  Like perhaps
> > > managers getting together and deciding production issues are a priority
> > and
> > > diverting resources dynamically to address them.  Building an awesome
> new
> > > feature will have a lot less impact if the users are hurting from
> growing
> > > disrepair.  It seems to me like if individual contributors and
> > maintainers
> > > could have solved this problem, they would have by now.  I'm a little
> > > worried that the only viable solution right now seems like heroes
> > stepping
> > > up to fix these bugs.
> > >
> > > Concretely, I think expanding something like the Core Platform Team's
> > > clinic duty might work.  Does anyone have a very rough idea of the time
> > it
> > > would take to tackle 293 (wow we went up by a dozen since this thread
> > > started) tasks?
> > > ___
> > > 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
> >
>
>
> --
> (http://cscott.net)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 

Re: [Wikitech-l] Getting surface headings from VE Model

[Ed Sanders]

I've filed https://phabricator.wikimedia.org/T254354 to track the updating
issue.

On Wed, 3 Jun 2020 at 15:04, Ed Sanders  wrote:

> ve.dm.Document contains a cache of nodes by type which you can access with
> ve.dm.Document.prototype.getNodesByType:
>
> ve.init.target.surface.model.documentModel.getNodesByType( 'mwHeading',
> true );
>
> This appears to work for the initial document, but may be broken with
> regards to newly added nodes.
>
> On Tue, 26 May 2020 at 10:43, Egbe Eugene  wrote:
>
>> Hi All,
>>
>> I am using the VE model in a Gadget and I am wondering how can I get the
>> headings which have been entered on the VE surface for further processing
>>
>> 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] Getting surface headings from VE Model

[Ed Sanders]

ve.dm.Document contains a cache of nodes by type which you can access with
ve.dm.Document.prototype.getNodesByType:

ve.init.target.surface.model.documentModel.getNodesByType( 'mwHeading',
true );

This appears to work for the initial document, but may be broken with
regards to newly added nodes.

On Tue, 26 May 2020 at 10:43, Egbe Eugene  wrote:

> Hi All,
>
> I am using the VE model in a Gadget and I am wondering how can I get the
> headings which have been entered on the VE surface for further processing
>
> 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] Etherpad conversion tools (was Re: Scrum of scrums/2019-05-29)

[Ed Sanders]

As mentioned in https://phabricator.wikimedia.org/T130970, the bullet lists
the Etherpad edit surface are terrible, but if you use the export feature
you get properly structured HTML which can be pasted into VisualEditor.

A better solution would be to have the collaborative editing directly in
MediaWiki in the first place: https://www.mediawiki.org/wiki/COLLABPAD

On Wed, 29 May 2019 at 22:09, Nick Wilson (Quiddity) 
wrote:

> On Wed, May 29, 2019 at 11:49 AM Željko Filipin 
> wrote:
>
> > To make meeting notes even easier to read, is there a tool that would
> > convert links to wikitext?
> > * https://phabricator.wikimedia.org/T221177 to [[phab:T221177]]
> > * https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/506043/ to
> > [[gerrit:#/c/operations/puppet/+/506043/]]
> > *
> >
> >
> https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage
> > to [[Growth/Personalized first day/Newcomer homepage]]
>
>
> The only existing (or documented at least) tool is here, but all it does is
> change single-linebreaks (without bulletpoints) into 
>
> https://wikitech.wikimedia.org/wiki/Etherpad.wikimedia.org#Converting_etherpad_content_into_wikitext
> E.g. it creates a complete mess if you run it on
> https://etherpad.wikimedia.org/p/Hackathon_showcase_template (because of
> the etherpad-style-bulletpoints)
>
> See also the semi-related https://phabricator.wikimedia.org/T130970
>
> If someone made a tool that converted etherpads into cleaned-up wikitext
> that would be great. It could be used for a variety of things including
> wikifying event-session notes and various team's weekly meeting notes.
> ___
> 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] Phabricator spam - account approval requirement enabled

[Ed Sanders]

+100

Also a tip for those of you wanting to clear up the resulting email spam:
you can temporarily turn off "conversation mode" in Gmail's settings, then
search for messages from CommunityTechBot or the spammer, and delete all
these emails without having to delete the threads they belong too.

On Mon, 2 Jul 2018 at 18:18, Joel Aufrecht  wrote:

> Thank you Leon for this heroic effort, and thanks to everyone who helped
> in this cleanup.
>
> On Mon, Jul 2, 2018, 9:58 AM Leon Ziemba 
> wrote:
>
>> The bot has now completed it's run. If you see any outstanding tasks that
>> need to be repaired, please give me the task IDs.
>>
>> The bot ran for roughly 36 hours, repairing at least 4,000 tasks (perhaps
>> many more).
>>
>> There were some issues with the bot that may still affect your tasks:
>> * The triage level was not restored, or was put in "Needs triage". This
>> was fixed around 16:00 UTC on July 1. Hundreds of tasks were affected.
>> * For most of the bot's run, it was subject to a newly imposed rate
>> limiting. If the rate limit was hit in the middle of repairing a task, the
>> bot may not have fixed everything. Many tasks were affected. This issue was
>> fixed around 15:00 UTC on July 1.
>> * For some tasks, the vandal removed tags as well adding some. The bot
>> did not properly restore the removed tags until around 12:00 UTC on July 2.
>> The number of tasks affected by this is estimated to be low.
>> * Some tasks have "custom fields" that were vandalized, which the bot did
>> not restore. An example is the "due date" on
>> https://phabricator.wikimedia.org/T193593. The number of tasks affected
>> by this should be very low.
>>
>> If you notice any tasks where the bot didn't fix everything, and you
>> don't want to fix it yourself, just give me the task IDs and I can re-run
>> the bot on those.
>>
>> Thanks to Andre, Mukunda, and everyone else to helped with this effort.
>>
>> ~Leon
>>
>> On Sun, Jul 1, 2018 at 8:49 PM Mukunda Modell 
>> wrote:
>>
>>> Hi Leon. I can't thank you enough for your efforts to help clean things
>>> up in Phabricator.  I can, however, help make the bot more effective. See
>>> below for responses inline.
>>>
>>> On Sun, Jul 1, 2018 at 10:47 AM Leon Ziemba 
>>> wrote:
>>>
 An update... the bot went to sleep as instructed a few hours after I
 went to sleep. Bot is now back up and running, with some ~4,500 tasks still
 to fix.

 A few problems:
 * The new "rate limiting" of the API is rather rigorous. Release
 engineering tried to whitelist the bot but we had no luck. So, it will take
 some time to go through everything.

>>>
>>> I'm still looking into why the bot hits the rate limit. I'm sure I can
>>> come up with a way to get it whitelisted.
>>>
>>>
 * If the bot hits the rate limit while editing a task, all other
 changes it was going to make to that task didn't happen. Hence you may see
 only some corrections on some tasks.
 * The priority level is now being set to "Needs triage". This is
 because the Conduit API gives me numbers for the priority level, and the
 edit API wants a string (?!?). I don't know what numbers are for what
 priorities, so "Needs triage" it is. Older versions of the script left the
 priority level unchanged, so either way you may wish to review the
 priorities of your tasks. If you know what the priority number to string
 mapping is, please tell me :)


>>> If you would like to alter the bot to restore the correct priority, this
>>> should help; The priority levels are configured as follows:
>>>
>>> {
>>>   "10": {
>>> "color": "sky",
>>> "keywords": [
>>>   "lowest"
>>> ],
>>> "name": "Lowest",
>>> "short": "Lowest"
>>>   },
>>>   "25": {
>>> "color": "yellow",
>>> "keywords": [
>>>   "low"
>>> ],
>>> "name": "Low",
>>> "short": "Low"
>>>   },
>>>   "50": {
>>> "color": "orange",
>>> "keywords": [
>>>   "normal"
>>> ],
>>> "name": "Normal",
>>> "short": "Normal"
>>>   },
>>>   "80": {
>>> "color": "red",
>>> "keywords": [
>>>   "high"
>>> ],
>>> "name": "High",
>>> "short": "High"
>>>   },
>>>   "90": {
>>> "color": "violet",
>>> "keywords": [
>>>   "triage"
>>> ],
>>> "name": "Needs Triage",
>>> "short": "Triage"
>>>   },
>>>   "100": {
>>> "color": "pink",
>>> "keywords": [
>>>   "unbreak"
>>> ],
>>> "name": "Unbreak Now!",
>>> "short": "Unbreak!"
>>>   }
>>> }
>>>
>>>
>>>
>>> Cheers,

 ~Leon

 On Sun, Jul 1, 2018 at 5:32 AM Max Semenik 
 wrote:

> We've got ourselves da MVP!
>
> On Sun, Jul 1, 2018 at 12:51 AM, Leon Ziemba <
> musikani...@wikimedia.org>
> wrote:
>
> > I wrote a rollback script, currently running as CommunityTechBot
> >  and
> previously
> > Community
> > Tech bot 

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Ed Sanders]

Where do I find links to the parent commit and child commit(s)? All I can
see currently is a link to the parent's diffusion commit(?!).

As someone who often commits a stack of 5+ dependent commits, these are
very useful to my workflow (or anyone reviewing my code).

On 22 July 2016 at 19:18, Bartosz Dziewoński  wrote:

> On 2016-07-21 01:02, Marcin Cieslak wrote:
>
>> my userid and a part of the search box are extending past right margin
>> off the screen, so I have to scroll to login (old version has this problem
>> too).
>>
>
> This is made worse by the new Gerrit by including more items in the
> default "My" menu. Luckily, it's customizable now, so after you log in, you
> can go to Settings → Preferences and remove some of them.
>
> --
> Bartosz Dziewoński
>
>
> ___
> 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 2.12.2 test instance - PLEASE TEST

[Ed Sanders]

Will it show multiple children (split trees?)

On 25 July 2016 at 15:23, Bartosz Dziewoński <matma@gmail.com> wrote:

> On 2016-07-25 16:20, Ed Sanders wrote:
>
>> Where do I find links to the parent commit and child commit(s)? All I can
>> see currently is a link to the parent's diffusion commit(?!).
>>
>> As someone who often commits a stack of 5+ dependent commits, these are
>> very useful to my workflow (or anyone reviewing my code).
>>
>
> They are under the dropdowns on the right, on the "Related Changes" tab.
> New Gerrit actually shows the whole stack there, rather than only direct
> children and parent.
>
>
> --
> Bartosz Dziewoński
>
> ___
> 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