Dead people could be designated authors of Atlassian Confluence docs and that can't be changed After The Register covered the eleven years and counting wait for Atlassian to deliver custom domain names for its cloudy products, readers pointed out an even older open request: CONFCLOUD-7247 was filed on November 1st, 2006 and asks the software upstart to allow changes to the author of an existing page of its Confluence …
Where I work, your user ID is based on your initials. Our brain-dead systems won't allow you to change a user's user ID: So people who change their name (marriage, divorce, gender reassignment, etc) have to keep their old ID which can be upsetting to some.
Of course, El Reg has long had a related issue. From Comments Guidelines:
Forum privileges are awarded according to your handle - not by user account. This means that if you change your handle, you will lose your forum privilegesM.
That is probably workable if you see one Confluence page as roughly equivalent to a complete document, but becomes intrusive to unworkable if there are lots of shorter pages (intended to be easy to digest when read online) or even very short to tiny pages.
For example, I was working on a "company glossary entries" page collection, where each page was just one glossary entry - so generally tiny - and you could create a complete glossary with just the links to the relevant items for your immediate requirements. Some entries in a glossary are nigh on trivial whilst others (expanding an acronym to point to the correct set of industry safety standards) could be critical to get right.
Having an author section and contact details for an entry pointing you to the Pantone and HTML hex for "Goldenrod", as used in the project logo, would be laughable, but SOP has to be consistent so in it would have to go...
But any approach like the one you suggest is just papering over the crack in the basic product (one of many such) so you have to use what works for you...
> “Regarding the specific issue of changing the author on a Confluence page, our evaluation of the effort versus value for customers has pushed it down lower on the list of priorities”
Says everything you need to know about Atlassian and their products. Let me translate that for you:
'After some investigation, we found out that this issue requires a horrendous amount of work, because of short-sighted, poor, decisions made during software development (which our products promote). When we told Business how much engineering time it would take, they said hell no. Since our software and processes don't take so called "low-priority" issues into account with relation to how long they've existed, this work will literally never be done'
Of course you can't. That is not what is being requested. What is being requested is that you have a product that works. Something you should have done before making it available.
Once upon a time, when you published your software, you had to make sure it worked because there was no Internet for you to post updates and leave people to manage themselves. If you failed to ensure your software was functional, you wouldn't sell, end of.
These days, with near-ubiquitous Internet access, you no longer care about making a fully functional product, you only care about making a product function enough - the rest will be dealt with by support team.
One guy working in a basement.
I like my FTTH, but sometimes, I long for the times when I could buy a product and it worked.
"These days, with near-ubiquitous Internet access, you no longer care about making a fully functional product, you only care about making a product function enough"
There's even a term for this. MVP - minimally viable product. A variation is MMP - Minimally marketable product.
MVP is *really* not meant to be used like that! You're not supposed to expose the final end user to the MVP, it is for the client's internal team!
But it is, sadly, only too easy to see how the term was abused to mean, as you put it, MMP: "hey, we can point to this page that says that an MVP is a Good Thing" and quickly put the book away before they read the actual description.
Add it to the long list of badly treated and totally incorrect language that makes up "Management Speech", along with the old favourites "quantum leap" and the upstart "steep learning curve".
“Solving the ability to change the author of an existing page is on our priority list [for 11 years so far]. Currently, we are focused on critical work to improve table formatting and performance for Confluence Cloud pages"
If incorrect authorship or ownership is not deemed a high priority something's seriously wrong with the thinking. There are rather more potential legal issues with that than with the formatting of tables. But that's developer thinking. I remember testing an accounting package that allowed invoices to be modified and deleted after issue. The devs didn't think anything was wrong with that.
I worked for a small company that sold an accounts package. Our own accountant was aghast that I could use some devil incantations called "SQL" to change the state of any ledger that was in the system - absolutely outrageous he said. About a day later he was busy, using this new found knowledge, "fixing" our accounts to be more in line with the management expectations.
> But that's developer thinking
Upvoted you for the "something's seriously wrong with the thinking" BUT
Excuse me, that is Atlassian bug triage thinking.
And as for your note about an invoicing system - well, that just sounds like that set of devs had insufficient domain knowledge; hey, they are devs, not accountants. In any project, you have to ensure that the devs are supplied with enough training/info to provide the domain knowledge. You did just update the specs and pass back some training materials, didn't you, rather than - as here - mock them just for knowing something you did but they happened not to?
In terms of documents being written by colleagues who have long since passed away, maybe it's nice to see that something they contributed is still relevant?
It's like the story of someone who lost their dad years ago, and they realised that their dad set a really fast time on a car racing game. So when he'd play, he'd be racing against the ghost car (representative of the fast time set) so it'd be like playing with his dad. But one day he realised he was faster than his dad, and if he finished the lap the time the dad set would be lost.
I mean it's irrelevant really to the conversation but it makes me think about loved ones who have long since gone, and then stumbling across something they made. It's a connection to a happier memory in a lot of ways.
I'm a new employee and I'd like to change my username. How am I supposed to sell our software using this address?
Lorenzo Servantez loser@somesoftwarecorp.com
Mr. Servantez,
Unfortunately, all email addresses are automatically generated by the system and cannot be changed. Please, believe me.
Regards, Biron Tchaikovsky bitch@somesoftwarecorp.com
we've long since moved to firstname.lastname@domain for emails.
...which doesn't work:
Falsehoods Programmers Believe About Names
All of these assumptions are wrong....
20. People have last names, family names, or anything else which is shared by folks recognized as their relatives.
...
39. People whose names break my system are weird outliers. They should have had solid, acceptable names, like 田中太郎.
40. People have names.
I have linked to that page before, but it bears repeating. People change names for many reasons, and systems that cannot cope with that are broken.
"we've long since moved to firstname.lastname@domain for emails"
unless you're from the part of the world where it would be familyname.forename@domain...
that's why Benny Hill would say 'in China it is so easy to ring the Wong number'
(discovered him, and Kenny Everett, lurking on one of the more obscure Freeview channels a couple of weeks ago)
In my previous role, I authored 100s of documents in multiple areas, I think I was only the owner of the ones in draft.
I was the person who went to a meeting, and everyone else at the table was accountable for drafting policies procedures and the like, but muggins was responsible for doing the work.
I sent NESA (NSW Educational Standards Authority) a Happy 18th Birthday card in July last year when the Information & Software Technology 7-10 Syllabus turned 18. Just looked and it is still the "current" syllabus.
I understand the Technology Inspectorate were not amused.
"Solving the ability to change the author of an existing page is on our priority list."
Oh, it is not just on any old list, it is on your PRIORITY LIST!
So, you have been using the "agile project management" of Jira FOR YEARS to get that done, and it is STILL NOT DONE?
Go sprinkle some more "Agile" on it. Infuse the project with "Kanban." Create some more nagging Jira tickets.
Finally, light some incense for all of your customers incensed by your hippie BS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
