Page MenuHomePhabricator

Create a beta cluster equivalent for the Wikimedia-production-error tag
Closed, DeclinedPublic

Description

See title.

Use case: I reported T344635 on August 21. As the proposed tag does not exist, I didn't add it. Now (okay, yesterday) ITSTHURSDAY, the error hits production and duplicate T344964 is reported.

Please don't ask me (and everyone else) to remember mentioning things in wherever the most recent train blocker thread is. (many people wouldn't even know about that at all, and I regularly forget) My hope is that with the proposed tag developers can more easily find train blockers themselves before deployment. Perhaps a bot could even do it by posting any recently opened bug reports with the proposed tag in the train blocker thread, but I'll leave that to the bot ops.

Event Timeline

@AlexisJazz: you can use train-blockers.toolforge.org to find the task for the current week. Most people probably wouldn't tag it correctly too in my opinion.

How would this be different from Beta-Cluster-reproducible?

I had tagged T344635 with Beta-Cluster-reproducible and it clearly didn't help. But more to the point: Beta-Cluster-reproducible covers more than errors. Thumbnailer acting a little odd on some niche image format? Beta-Cluster-reproducible. Some very odd wikicode confuses ParserFunctions? Beta-Cluster-reproducible. Neither of which are train blockers.

@AlexisJazz: you can use train-blockers.toolforge.org to find the task for the current week. Most people probably wouldn't tag it correctly too in my opinion.

Didn't know about that ToolForge link, so thanks for that, but I'm still likely to forget.

A tag is just easier to add. Even if the reporter doesn't add it, Aklapper or (in this case) @Umherirrender or @Nikerabbit or @abi_ possibly could have.

and it clearly didn't help.

We won't fix either a social or a workflow problem by introducing competing workflows. :) Thus declining.

In my understanding, going to Edit Related Tasks... and selecting Edit Parent Tasks is the workflow to mark an issue as a train blocker, after looking up the current train task ID.

and it clearly didn't help.

We won't fix either a social or a workflow problem by introducing competing workflows. :) Thus declining.

In my understanding, going to Edit Related Tasks... and selecting Edit Parent Tasks is the workflow to mark an issue as a train blocker, after looking up the current train task ID.

I'll rarely do that. In this case, I didn't even realize while reporting that it would be a train blocker.

Adding tags/categories I can do, and many users do. Unlike you, I'm not getting paid so telling me how I should work, especially when it's not particularly intuitive, is unlikely to pay off.

I'm not your enemy, I'm trying to help, and declining a proposal that makes that easier is not helpful. Whether in the proposed form or some other way, you do see the problem as well. But a social/workflow problem is not solved by you bluntly telling me what to do. That generally works on people you pay, but many of us do not fall into that category.

Thus I will be helpful once more and reopen this task to allow for more input. You're welcome, of course.

Aklapper changed the task status from Open to Stalled.Aug 25 2023, 4:57 PM
Aklapper triaged this task as Low priority.
Aklapper moved this task from Incoming to Projects to create on the Project-Admins board.

Unlike you, I'm not getting paid so telling me how I should work, especially when it's not particularly intuitive, is unlikely to pay off.

Sure. That's why I pointed out existing workflows, and not using existing workflows definitely won't pay off either... :-/

Unlike you, I'm not getting paid so telling me how I should work, especially when it's not particularly intuitive, is unlikely to pay off.

Sure. That's why I pointed out existing workflows, and not using existing workflows definitely won't pay off either... :-/

The alternative is you bully bug reporters away. I hope you'd a agree that's not a real solution.

The existing workflow is crap. There, I said it. People don't know about it and even if they do, they don't follow it. @abi_ works for the WMF, saw the task in time, and DIDN'T mark it as a train blocker. This is not an education issue.

There are other ways this could be improved, for example:

  • Add a "this a might be a train blocker" checkbox on the new task form that automatically links it with the appropriate train blocker task.
  • Have a bot search for recently opened tasks with Beta-Cluster-reproducible and link them with the appropriate train blocker task. (but this may cause false positives as Beta-Cluster-reproducible covers more than errors)
  • If you don't really want to "use" the proposed tag, have a bot automatically link tasks with the proposed tag to the train blocker thread and then remove the tag.
    • You could even have multiple tags and let that bot handle them all the same way. "Javascript error", "Potential trainblocker", "API error", "403 forbidden" etc. Increasing the odds a user adds an appropriate tag.
  • Forcefully educate all WMF staff, including yourself, to follow the current workflow. You are added as a subscriber to everything, so why didn't YOU tag T344635 as a train blocker? As you see, playing the blame game is easy, but it doesn't help anyone.

As a human, I can describe the task for what it is. In this case, a JS error. The leap to "potential train blocker" is more complicated and not as intuitive, and unpaid users can't be expected to make that leap. Even paid contributors don't consistently manage this. (this kind of thing has happened before)

so why didn't YOU tag T344635 as a train blocker? As you see, playing the blame game is easy, but it doesn't help anyone.

Either nobody realized that it should have been marked as a train blocker, or nobody considered it a train blocker given human judgement at that point in time.
I tried to explain above how anyone who thinks an issue might be a train blocker could mark it as such regarding current workflows. Looks like I failed as I do not think that anyone played a "blame game" and as I don't understand why replies in this ticket were immediately taken to a personal level which I do not enjoy.
*If* you think that bug reporters get "bullied", then I'd kindly ask you to refer to https://www.mediawiki.org/wiki/Code_of_Conduct to report a problem - thanks!

so why didn't YOU tag T344635 as a train blocker? As you see, playing the blame game is easy, but it doesn't help anyone.

Either nobody realized that it should have been marked as a train blocker, or nobody considered it a train blocker given human judgement at that point in time.
I tried to explain above how anyone who thinks an issue might be a train blocker could mark it as such regarding current workflows.

Personally, I didn't realize it. I have a lot on my mind, am unpaid (it's unreasonable to hold me to the same standards as the paid workforce) and the workflow is not intuitive.

Looks like I failed as I do not think that anyone played a "blame game" and as I don't understand why replies in this ticket were immediately taken to a personal level which I do not enjoy.

You said this:

We won't fix either a social or a workflow problem by introducing competing workflows. :) Thus declining.

The way this comes across (but perhaps I'm seeing this wrong?) is that you indirectly blame me, saying I should have followed the unintuitive workflow.

The reason it became semi-personal is because despite acknowledging that an issue exists, you closed this task as "declined" a mere 14 minutes after it was opened. This would never happen on, say, English Wikipedia. Any half-reasonable proposal/suggestion/discussion is normally left open for at least a few days, typically until it gets archived due to inactivity. Swift closures go against the spirit of collaboration and prevent discussion of underlying causes and alternative solutions.

*If* you think that bug reporters get "bullied", then I'd kindly ask you to refer to https://www.mediawiki.org/wiki/Code_of_Conduct to report a problem - thanks!

Please don't open that can of worms. I got a warning some time ago, had zero clue what the warning was for, still don't know, wasn't given a link to the supposedly offending comment and the reporter revels in anonymity. Some wiki contributors perceive Phabricator as a hostile environment, and since that warning I fully understand why. Getting warned not having a clue what you did wrong is a horrible experience. Because of this, I don't feel safe here.

I'm half-expecting another one of those vague warnings (maybe even a block) for speaking my mind here - if that happens, so be it. I know I didn't attack anyone. I know I'm trying to be constructive.

In this context, "bullying" is about perception. The rigid "our way or the highway" attitude (the existing workflows must be followed, end of discussion), at least that's how it comes across whether intended or not, can very much be perceived as bullying - even if not intended as such.


Regarding the original issue, On wiki there are gadgets, userscripts, common.js, etc. To what degree are such things possible on Phabricator? I know Greasemonkey/Tampermonkey can be used for such things, but I mean without browser extensions.

Here is some quick and dirty code:

//This code is hereby irrevocably released as WTFPL Version 2[www.wtfpl.net/about/]
//Due to CORS/CSP this does not work
//fetch('https://train-blockers.toolforge.org/', {
//    redirect: "manual"
//}).then((res) => {

res = {}
res.url = 'https://phabricator.wikimedia.org/T343725' //hardcoded current result from train-blockers.toolforge.org because CORS/CSP

	for (int=0;int<document.getElementsByClassName('phabricator-handle-tag-list-item').length;int++){

		if ( document.getElementsByClassName('phabricator-handle-tag-list-item')[int] ) {
			if ( document.getElementsByClassName('phabricator-handle-tag-list-item')[int].children[0].href.replace('https://phabricator.wikimedia.org/tag/','') == 'beta-cluster-reproducible/') {
				document.getElementById('UQ0_82').children[0].click()
				var InsertTask = setInterval(function(){ //yes I am evil
					//console.log('ARE WE THERE YET?');
					int++;
					if ( int > 100 ) {
						clearInterval(InsertTask);
					}
					if ( document.getElementsByClassName('phabricator-object-selector-search')[0] && document.getElementsByClassName('phabricator-object-selector-search')[0].querySelectorAll('input')[0] ) {
						clearInterval(InsertTask);
						document.getElementsByClassName('phabricator-object-selector-search')[0].querySelectorAll('input')[0].value = res.url.replace(/.*\/(T[0-9]+)$/,'$1');
						document.getElementsByClassName('aphront-dialog-tail')[0].querySelectorAll('button')[0].click()
					}
				},100);
			}
		}
	}


//}).catch();

This would preferably be combined with the proposed tag as beta-cluster-reproducible is too broad. And using the Phabricator API would be better, but according to https://stackoverflow.com/questions/37489926/connect-to-phabricator-conduit-api-with-pure-javascript that requires going to one's settings and obtaining a token first. I prefer a GUI hack over that.

Personally I'd prefer a bot to handle this.

Thank you @AlexisJazz for reporting the issue in question (T344635). I want to apologize for dropping the ball on that ticket.

When I reviewed the ticket, I immediately made the assessment that the issue is severe, triaged it as high priority and submitted a fix for it. I was not sure about marking at as UBN!, and a train blocker, but went ahead and submitted a back-port patch in case someone judged that it was a train blocker. Looking back, I should have marked it a train blocker and back-ported it. Note to self: when in doubt, err on the side of caution, make noise and get multiple inputs.

I do not have a lot to add to the current discussion, the processes that come to my mind are a bit redundant to what we already have. In general, I think It would be nice to have more eyes on high priority bug reports after group0 deployment in order to reduce the impact of error in judgements.

Thank you @AlexisJazz for reporting the issue in question (T344635). I want to apologize for dropping the ball on that ticket.

When I reviewed the ticket, I immediately made the assessment that the issue is severe, triaged it as high priority and submitted a fix for it. I was not sure about marking at as UBN!, and a train blocker, but went ahead and submitted a back-port patch in case someone judged that it was a train blocker. Looking back, I should have marked it a train blocker and back-ported it. Note to self: when in doubt, err on the side of caution, make noise and get multiple inputs.

I do not have a lot to add to the current discussion, the processes that come to my mind are a bit redundant to what we already have. In general, I think It would be nice to have more eyes on high priority bug reports after group0 deployment in order to reduce the impact of error in judgements.

Thank you for this comment. I don't blame you at all, I'm a firm believer in automation where possible instead of relying on humans to remember things or repeatedly carry out complex instructions.

I suspect UBN! wouldn't have been appropriate as I think (but I could very well be wrong) that only applies to considerable issues on production. Though I also vaguely remember the importance being solely at the discretion of whoever claims a ticket as they use it to prioritize their own work.

I agree with @Aklapper that competing workflows would be bad, but different converging workflows should be helpful. Different people work in different ways. Maybe some find it easy to consider whether something is a train blocker, look up the train blocker task and edit the parent task of their newly created bug report. Annoyingly, the parent task can't be configured on the new task form AFAICS, which is another reason why a tag would be easier.

Once a tag is added this should ultimately merge back into existing workflows, preferably automatically.

I suspect UBN! wouldn't have been appropriate as I think (but I could very well be wrong) that only applies to considerable issues on production.

Anything that blocks the train is unbreak now

I suspect UBN! wouldn't have been appropriate as I think (but I could very well be wrong) that only applies to considerable issues on production.

Anything that blocks the train is unbreak now

Thanks, learned something.

Okay, so I improved my little script to the point where it should be useful. I can't remove tags though as that requires interaction with a dropdown, which is apparently impossible to automate. Adding a parent task can be done without dropdowns though. It's absolutely hilarious. Something should be added to stop it from loading when the UI language is not English. Not a problem for me, though..

Now the question is: is there something akin to common.js here on Phabricator, or can this be installed like a gadget or something? (and can we have a tag that isn't as broad as Beta-Cluster-Reproducible so the auto submit can be enabled?)

// ==UserScript==
// @name     omgtb Phabricator
// @version  1
// @grant    none
// @match    https://phabricator.wikimedia.org/T*
// @run-at	document-end
// ==/UserScript==

/*
This code is hereby irrevocably released as WTFPL Version 2[www.wtfpl.net/about/]

This script checks if the viewed task may be a potential train blocker you just filed and opens the "add parent task" screen. There is a line of code you can uncomment to automatically submit as well, but unless https://phabricator.wikimedia.org/T344999 gets approved this is probably not a good idea as beta-cluster-reproducible is too broad

It also adds a "Mark as train blocker" link

omgtb = Oh My God Train Blocker

To test this script raise the default value of 120000 for maximum age to, I dunno, 157680000000 (5 years) and find a task YOU filed with the Beta-Cluster-reproducible tag. Just paste the script in the console

much of this BS is because the task creation form doesn't allow the parent task to be specified, so we have to check whenever viewing a task:
1. if you filed it
2. if you filed it RECENTLY
total bloody waste if you ask me
and no elements have reasonable classes or IDs so I made this brilliant function called omgtb.getElThatReads which does something absolutely hilarious
hint: it only works in English
*/
/*jshint esversion:8*/
async function getTaskList() {
	omgtb.taskListHTTP = await fetch('https://train-blockers.toolforge.org/api.php');
	omgtb.taskList = await omgtb.taskListHTTP.text();
	omgtb.setParentTask(omgtb.taskList);
}
if ( document.location.href.match(/https:\/\/phabricator\.wikimedia\.org\/T[0-9]+$/) ) { //only run on task pages
	var omgtb = {};

	omgtb.strText = {};

	omgtb.strText.en = {
		'Authored By':'Authored By',
		'Flag For Later':'Flag For Later',
		'Select':'Select',
		'Save Parent Tasks':'Save Parent Tasks',
		'Edit Related Tasks...':'Edit Related Tasks...',
		'Edit Parent Tasks':'Edit Parent Tasks',
		'tagname':'Beta-Cluster-reproducible'
	};
	omgtb.lang = 'en';
	omgtb.str = omgtb.strText[omgtb.lang];
	omgtb.WhoAmI = document.getElementsByClassName('phabricator-core-user-menu')[1].href.replace(/.*\/([^\/]+)\/$/,'$1');
	omgtb.getElThatReads = function(selector,linkInnerText,int2) { //returns element that matches query and innerText
		omgtb.linkEls = document.body.querySelectorAll(selector);
		for (int2=0;int2<omgtb.linkEls.length;int2++){
			if ( omgtb.linkEls[int2] && omgtb.linkEls[int2].innerText.match(linkInnerText) ) {
				return omgtb.linkEls[int2];
			}
		}
	};
	omgtb.TaskFiler = omgtb.getElThatReads('.phui-curtain-panel-header',omgtb.str['Authored By']).parentElement.querySelectorAll('.phui-link-person')[0].href.replace(/.*\/([^\/]+)\/$/,'$1');
	omgtb.tblink = omgtb.getElThatReads('.phabricator-action-view-item',omgtb.str['Flag For Later']).parentElement.cloneNode(true);
	omgtb.tblink.querySelectorAll('a')[0].innerHTML = '<span style="font-weight:bold;color:red">Mark as train blocker</span>';
	omgtb.tblink.querySelectorAll('a')[0].href = '';
	omgtb.tblink.id = 'trainblocklink';
	omgtb.tblink.onclick = function(){omgtb.force=1;getTaskList();};
	omgtb.getElThatReads('.phabricator-action-view-item',omgtb.str['Flag For Later']).parentElement.parentElement.appendChild(omgtb.tblink);
	omgtb.waitForSearch = function() {
		omgtb.int = 0;
		var waitForSearch = setInterval(function(){ //yes I am evil
			console.log('waiting for the search.. are we there yet mate?');
			omgtb.int++;
			if ( omgtb.int > 50 ) {
				clearInterval(waitForSearch);
			}
      omgtb.searchResultCount = document.body.querySelectorAll('.phabricator-object-selector-results .phabricator-object-selector-row').length;
			if ( omgtb.searchResultCount > 0 && omgtb.searchResultCount < 5 ) { //as we entered the exact task we want, the presence of a single row would mean it's done.. except sometimes this still returns more than one result
				omgtb.getElThatReads('a.button',omgtb.str.Select).click();			
				clearInterval(waitForSearch);
			}
			omgtb.getElThatReads('button',omgtb.str['Save Parent Tasks']).focus();
			//omgtb.getElThatReads('button',omgtb.str['Save Parent Tasks']).click(); //submit parent task
			},100);
	};
	omgtb.guiHack = function() {
		omgtb.getElThatReads('.phabricator-action-view-item',omgtb.str['Edit Related Tasks...']).click();
		omgtb.getElThatReads('.phabricator-action-view-item',omgtb.str['Edit Parent Tasks']).click();
		omgtb.int = 0;
		var InsertTask = setInterval(function(){ //yes I am evil
			console.log('waiting for parent task editing screen to open.. are we there yet mate?');
			omgtb.int++;
			if ( omgtb.int > 50 ) {
				clearInterval(InsertTask);
			}
			if ( document.getElementsByClassName('phabricator-object-selector-search')[0] && document.getElementsByClassName('phabricator-object-selector-search')[0].querySelectorAll('input')[0] ) {
				clearInterval(InsertTask);
				document.getElementsByClassName('phabricator-object-selector-search')[0].querySelectorAll('input')[0].value = omgtb.trainBlockerTask;
				document.getElementsByClassName('phabricator-object-selector-search')[0].querySelectorAll('input')[0].dispatchEvent(new KeyboardEvent('keydown', {
					'keyCode': 37
				})); //trigger search
				omgtb.waitForSearch();
			}
		},100);
	};
	omgtb.setParentTask = function(tbjson) {
		omgtb.trainBlockerTask = JSON.parse(tbjson).current.task_id;
		console.log('Train blocker task: '+omgtb.trainBlockerTask);
		if ( omgtb.getElThatReads('.phui-tag-core',omgtb.str.tagname) || omgtb.force ) {
			omgtb.guiHack();
		} else {
			console.log('couldn\'t find the tag mate');
		}
	};
	if ( omgtb.WhoAmI == omgtb.TaskFiler ) {
		console.log('you\'re responsible for this task mate');
		omgtb.FileDate = Date.parse(document.getElementsByClassName('phui-side-column')[0].querySelectorAll('.print-only')[0].innerText.replace(/ \(UTC.*$/,''));
		omgtb.TimeSinceFiling = (new Date().getTime() - omgtb.FileDate);
		if ( omgtb.TimeSinceFiling > 0 && omgtb.TimeSinceFiling < 120000 ) { //120000ms = filed in the past 2 minutes
			getTaskList();
		} else {
			console.log('nah whatever mate this is old news ('+omgtb.TimeSinceFiling+'ms old)');
		}
	} else {
		console.log('you didn\'t file this task mate');
	}
} else {
	console.log('this ain\'t no task mate');
}

Edit: put language dependent strings near the top in one object, added header to execute as Greasemonkey script

Edit 2024-02-27: use train-blockers.toolforge.org, see T352167#9575683

Thus I will be helpful once more and reopen this task to allow for more input.

I'd still decline this as input seems to have been provided...

Thus I will be helpful once more and reopen this task to allow for more input.

I'd still decline this as input seems to have been provided...

A bit more input has been provided now, but I'm saddened to see that while it is recognized that there is an issue, there doesn't seem to be much willingness to actively try and improve it.

I've added metadata for Greasemonkey to my script above. @abi_ : It also adds a "Mark as train blocker" link to all tasks so you don't have to visit train-blockers.toolforge.org in another tab/window and go through all the menus. My hope is that streamlining this process would make people hesitate less when considering to mark something as a train blocker.