Armen [:armenzg] Reporter
	Description • 10 years ago

Right now they are always at the bottom of the page for each pool.

Some of these slaves are forgotten.
I will add a note on the wiki page to help get to them, however, I would like a page dedicated to them to help review them.

	Justin Wood (:Callek)
	Comment 1 • 10 years ago

Would losing them below the 'broken' slaves and above the working ones solve your use case here?  I feel a separate page will just get ignored

	Justin Wood (:Callek)
	Comment 2 • 10 years ago

(In reply to Justin Wood (:Callek) from comment #1)
> Would losing them below the 'broken' slaves and above the working ones solve
> your use case here?  I feel a separate page will just get ignored

err would listing them below the 'broken' slaves and above the 'working' slaves on each types page....

	Armen [:armenzg] Reporter
	Comment 3 • 10 years ago

That would also work.

	Jordan Lund (:jlund)
	Comment 4 • 10 years ago

my 2c is in line with Callek:

swap the default of ordering our slave health lists by 'enabled in slavealloc' with 'state' column. This would put disabled slaves up higher but 'broken' will still show before 'disabled'.

FWIW: I have gone through some machines where we have the worst track record of wait times just in case there are instances where the problem tracking bug is resolved (which results in the slave hiding on the 'Buildduty report'). But generally I prefer the bduty report for iterating over slaves.

	Chris Cooper [:coop] (he/him)
	Comment 5 • 10 years ago

I feel like we're letting our tools take the blame for bad practice here. The slaves are clearly marked as disabled, they just happen to be at the bottom. If we can't be bothered to scroll (there are keyboard shortcuts to jump to the bottom of a webpage... Fn+Right arrow on Mac), we've already lost.

What we really need to do is audit *all* disabled slaves and annotate why they're each in that state.