Bonum Certa Men Certa

Sirius Lying About ISO to Justify Giving the Technical Staff Some Classic 'Bullshit Jobs' While Censoring/Covering Up Incompetence

ISO perception; ISO reality



Summary: Sirius 'Open Source' has long used "ISO" -- and sometimes "GDPR" -- as catch-all excuses for all sorts of nonsensical policies; does ISO realise the degree to which it is being misused by incompetent 'box tickers'?

"The ISO will basically standardize anything they're paid to even if it's impossible for anyone else to implement the standard, for any reason," Ryan said in IRC yesterday. "They're a corrupt group that will do anything for money."



"Here's one example from Sirius: Nothing to do with ISO, yet "ISO" gets mentioned all the time --- the go-to excuse for everything."To make matters worse, ISO facilitated epic Microsoft corruption. ISO still enables crime. It didn't seem to mind it or worry about it. It only worried about the impact on its image/reputation. The EPO's management also habitually uses "ISO" to distract from the EPO's crimes. We covered several examples several years ago. "The ISO hoards "standards" and won't let you read them for free," Ryan said moments ago. "So on top of patents, things only Microsoft can implement, etc. There's this. Unless you tore apart LAME's source code and tried to write new documentation for MP3, you can't share high level documents with anyone. I doubt that the paywall is a huge cash cow for them. You still can't share the official MP3 specification. The source code to LAME or Helix are the specification you can see without ponying up almost $300 iirc for a specification that describes it at a high level. By looking at source code, you can't clearly understand every part of it unambiguously unless you're a Mentat or something. The developers of LAME buy the PDFs but how much revenue is five people buying PDFs? Or maybe a dozen people even?"

Here's one example from Sirius: Nothing to do with ISO, yet "ISO" gets mentioned all the time --- the go-to excuse for everything. Any terrible policy.... such as classic "bullshit jobs" (making lists of tickets aside from the ticketing system, for no actual purpose other than to keep us extra busy).

Skip to the bold bits for the 'short' story or the gist:

Ticket Review - This is priority and compulsory

-------- Forwarded Message -------- Subject: Re: Ticket Review - This is priority and compulsory Date: Fri, 31 May 2019 12:45:09 +0100 From: xxxxx

xxxx,

Support is contracted to work 8 hours. This time should be used productively for the company’s requirements and business needs. And right now business needs this report from every shift to update the clients. We are also going through quality control for ISO purposes [Ed: emphasis ours]. This makes it even more important.

This is how your shift should really go:

1. Start shift 2. Read Handover 3. Respond to any emails 4. Ticket review 5. As and when new tickets are added to xxxx - enter these onto the relevant ticket review reports on the fileserver for each customer - whilst doing the ticket review, update if status has changed to either open - ongoing OR closed.6. Work on tickets/check monitoring etc for rest of your shift 7. Write detailed handover and send 8. Finish shift

It is not an unreasonable requirement from management.

If you have anymore issues email me directly or xxxx and do not cc anyone else as I don’t want a long email thread which is going to take focus away from objective.

Kind Regards,

xxxx

> xxxx wrote: > > I'm sorry you don't want my input, but I think this is a very important point that needs making. The trouble is that I can't see how this is going to improve the amount of tickets that we have open at the moment. What is needed is for each of us to actually work on the tickets. > > On 31-05-2019 11:35, xxxxx wrote: > >> Hi xxxx, >> The status box requires open/ ongoing or closed. It doesn't require details. >> Please read my email again and follow instructions. >> This is compulsory and required from each of you. >> This really is not open for discussion. > > [...] > >> <xxxxxxx> wrote: >> >> I understand. But it would be helpful for me if you would would >> clarify what exactly is required by a Ticket Review. For me, >> there's no point writing largely irrelevant or obvious comments >> at the bottom of each ticket. What is needed is to actually work >> on each ticket and resolve it so it can be closed.


Well, that stopped getting done when they decommissioned our last server. So that clearly had nothing to do with "ISO". The management lied to us and misused the "ISO" straw man.

Does ISO deserve to know this?

Another unqualified "manager" did the same with "GDPR". To provide some context (2020 E-mails):



> Hi Roy, > > Why was this handover sent at 1:03 am - your shift is meant to be > finished at 1:30 am. > > What is the reason for this?

Again, I think this is a misunderstanding. Check the past 8 years' worth of handovers at 1-1:30am. Look at the time pattern.

Did you send a similar message to all my NOC colleagues as well?

Regards,


She didn't 'get' the message. I did nothing wrong at all. We all did the same thing even close to a decade earlier. She wrote:



Hi Roy,

Why did you leave your shift at 1:14 am (Tuesday 3rd March 2020)? Your shift is meant to be until 1:30 am. There was no prearranged time change request with management or request to leave 15 mins early in writing from you in our records.

I am concerned with this issue. Would you kindly clarify?



I responded again:



> Hi Roy, > > Thanks for your email. > > I raised these questions yesterday as I noticed that you said bye on > your slack convo at 1:14 am (I have sent you a screen shot in previous > email) that made me investigate further and I came across your handover > times. Hence all these questions. > > We would request you to complete your full shift as prescribed and not > leave early in future.

My handover times are not different from my colleagues'.

Can you explain further please?

Regards,


I responded yet again:

> Hi Roy, > > Why did you leave your shift at 1:14 am (Tuesday 3rd March 2020)? > Your shift is meant to be until 1:30 am. > There was no prearranged time change request with management or request > to leave 15 mins early in writing from you in our records. > > I am concerned with this issue. Would you kindly clarify?

This is a very surprising message.

For the 9+ years I've been in the company we all (always) handed over at 1 to 1:30am, often leaving before 1:30. The above is not at all out of the ordinary. For any of us...

Regards,


At this point, bearing in mind the previous year's bullying by her, I kept a copy of the message as a reference (HR, hired by Sirius, advised me to keep copies of key correspondence due to perceived witch-hunts).

To quote the Office Manager on "GDPR" (message redacted a little):

Hi Roy,

When on the 3rd shift (17:30 - 01:30) your shift finishes at 01:30 not beforehand.

xxxx simply requested that you comply with your correct working hours as we could see on slack and your time tracker that you have not been working up until the end of your shift. This isn’t an unreasonable request and doesn’t need to be questioned, its quite simple, finish your shift on time.

I understand the handover being sent over between 01:00 - 01:30 as that allows the colleague next on shift the opportunity to read the handover and discuss anything with you.

On another note, if you can please keep these emails within the company - I can see you have responded/cc’d from your personal email. With GDPR being very important, I do not want any of our client/Sirius data being available on your personal email so its essential to keep work-related correspondence to work emails.

I hope this clears everything up for you.

Kind Regards,

xxxx


I also said:

>> Hi Roy, >> >> Thanks for your email. >> >> I raised these questions yesterday as I noticed that you said bye on >> your slack convo at 1:14 am (I have sent you a screen shot in previous >> email) that made me investigate further and I came across your handover >> times. Hence all these questions. >> >> We would request you to complete your full shift as prescribed and not >> leave early in future. > > My handover times are not different from my colleagues'. > > Can you explain further please?

I have received no reply for a day.

I am used to that.

This is not the first time I get unwarranted bollocking and it's the kind of thing that can drive away experienced and crucial colleagues over time.

What I did wasn't wrong; it doesn't hurt to get an apology for trying to shame me in front of the CEO for something I did which was not wrong.

Kind regards,


Of course she never bothered to apologise. She just vanished. Her sidekick had to audacity to say that slang like "bollocking" was rude, ignoring how rude the bullying was and instead focusing on style and choice of words (that British slang isn't even rude, unlike "bullocks"). It should be noted that the bullying did not start and stop in 2019; it carried on well into 2020. The above example is one of several.

"Sirius has a culture of extreme secrecy, even for insiders."In summary, what we deal with here is two people bullying staff. They're not qualified for any management role, but they seem to enjoy the 'thrill' of pretending that they are. It would become a more persistent problem as new imposters would attempt to cover up the company's gross understaffing, e.g. a person without knowledge and ill-equipped or unequipped on the beat, pretending to cover a NOC shift or offer a service (that's the CEO).

The company was lying to clients.

Remember that this is a company where there's no chance at progression except through nepotism (like family/kinship and sex). At the moment it's very hard to know what happens in the company, but that's hardly different from how it was before, as a cabal was working behind the scenes and behind our backs, scheming to do all sorts of illegal things while lying to us (about who left, who was becoming a client and so on)

Sirius has a culture of extreme secrecy, even for insiders. Someone needs to show the 'dirty laundry'.

In closing, to quote Ryan again (as other than Microsoft's OOXML crimes there's the MPEG cartel ISO controversy): "The ISO is still impeding LAME because someday they'll lose all of the people who understand the code and then someone will have to fix it up to continue working. I'd argue that you almost can't have standards with ISO. You have to publish them without ISO into the public domain to truly call them standards. People should get these Public Domain documents and decide whether it's a standard themselves or not, like ZIP or Opus. You'll notice they didn't go to the ISO with Opus. They went to the IETF. The IETF standard, you can read. You can read every draft copy too so you know how it changed along the way if you care to. The ISO won't give you drafts of a standard even if you pay so there's no seeing how the process evolved. The ISO is probably even nasty in ways that I can't fathom. But the ones that I know of are bad enough. FhG was not happy about LAME, I can tell you that much. Not happy at all. Even though it made MP3 hugely popular. They don't acknowledge it even once on their Web site, even their little "MP3 History" museum, which I don't even think mentions music piracy either. So that's kind of like "Wikipedia-izing the History of MP3". We'll just gloss over Napster and LAME. Wasn't important. Not gonna go how the format would have failed completely. We marketed it brilliantly and it was a hit out of the ballpark based on secret documents and patents, and ISO. Secret documents, patents, and ISO are in the way of progress, constantly, and the secret documents and ISO can be cut out of the process a lot easier than reforming the patent system."

How about "ISO" being leveraged to lie to staff?

Recent Techrights' Posts

"Security Advantages" Explained by a Scammy "Security" Site That Uses LLMs to Spew Out Garbage
destroying the Web by saturating it with "bullshit".
Over at Tux Machines...
GNU/Linux news for the past day
 
Certificate Authority Let's Encrypt Falls to 0.7% in Geminispace (It Was Around 12% Just 2 Years Ago and 7.5% This Past February)
Let's Encrypt is down again
Gemini Links 13/10/2024: Self-hosting Snac2 and Invasion of e-ink
Links for the day
SDxCentral, which the Linux Foundation Paid to Produce Marketing SPAM, Has Now Become Slop (LLM Spew) Disguised as 'Articles'
Google should delist it
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Saturday, October 12, 2024
IRC logs for Saturday, October 12, 2024
Links 12/10/2024: More Site Blocking, China's Hostility, and Evan Gershkovich's Upcoming Book
Links for the day
Links 12/10/2024: Boeing to Cut 17,000 Jobs, Medieval Sleeping Habits, Warning About Liquidweb
Links for the day
Links 12/10/2024: Health, Safety and Climate Concerns
Links for the day
Gemini Links 12/10/2024: Ensemble and Assembler
Links for the day
Links 12/10/2024: TikTok Layoffs and Risk of More Wars
Links for the day
IRC Proceedings: Friday, October 11, 2024
IRC logs for Friday, October 11, 2024
Gemini Links 11/10/2024: Against Cynicism, on Atheism, and Dropping Off The Internet
Links for the day
IBM Employees Smell Another Wave of Mass Layoffs (and Explain the Signs)
IBM currently has the policy of hiding the layoffs from shareholders and from the press using NDAs
Links 11/10/2024: Lots More Censorship and Growing Concerns About Health Impact of Social Control Media
Links for the day
Going Almost 4.5 Decades Back to Find 'Dirt' on a Person
That incident was 42.5 years ago. Is that how far some people would go in an effort to discredit a person?
XBox is Dead. This is Just the Beginning.
the main reason Microsoft bought Activision/Blizzard was to hide the growing losses and failure of XBox
The Risk to the "Linux" Brand
Brands that are not guarded from misuse/abuse will inevitably lose their original meaning and their value
Gemini Links 11/10/2024: Deploying Common Lisp Programs and Examining FreeBSD
Links for the day
Links 11/10/2024: Discord Still Blocked in Turkey, Google Might be Split
Links for the day
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Thursday, October 10, 2024
IRC logs for Thursday, October 10, 2024