I have no idea why you're being downvoted - this is true.
Atlassian produce some of the worst tech on the planet. Trying to administer this crap is horrible.
And don't get me started on how many project managers spend all day staring at Jira tickets instead of actually talking to their teams. Management-by-Jira is a disease, a symptom of bad organisational culture.
I'd rather get a fully-formed Jira ticket, than a terse three-word titled empty ticket, that the PM will explain in a 9AM Zoom meeting. Just me though.
But jira is only a tool right? Blaming Atlassian for a poorly led organization seems slightly misguided.
At some project size, measured either by software complexity/interoperability or user base, you will need a tool to manage issues and tasks.
What you're talking about is an organization where developers are not empowered - but even empowered developers need an issue tracker or a board of some description.
A "management by jira" culture will not be remediated by tooling.
A good tool cannot guarantee good results, but a bad tool can shape its user's behavior in bad ways. The same individual without that tool might have behaved differently. I have seen this in what I call design-by-ticket where all the why and how for a design decision, including design by committee meeting notes, get put in jira tickets.
It is hard to say for sure, but this organization used configuration controlled documents for design documentation before atlassian came along. When they made the switch (and hired oodles of graduates) suddenly about half of them ignore confluence or latex for design, because "jira has markdown". Oh hurray, we have a bad typesetting language mixed in with our bug tracker, lets shove our entire design in there! It is possible this is the influence of the graduates we hired, but it felt like everyone got there together while playing with the new toy.
Can't but help to feel that what you describe is a breakdown of both organization and work process.
It wasn't atlassian that "came along" - someone penned down an agreement and, from what it sounds, there was a lack of clarity both in regards to current and future principles of work and collaboration.
What we can do, as devs, to protect ourselves from the madness you describe is to be explicit about our work processes and their purpose.
Nothing much, but just a set of agreed upon principles and ways of working which should have nothing to do with tools.
What you end up with, by being explicit, is for having "something" to be supported by one or several tools.
Makes it easier to evaluate, select and change tooling that is fit for purpose.
The thing I've found is that Jira has so many fields on its tickets that beg to be filled in, that PMs start filling them in, and before you know it they're all mandatory and must be filled in. And organising that much state in the tickets becomes a full-time job, and so the PM ends up doing that - managing the state of Jira rather than managing the state of the project. The two become synonymous when they're not. When they inevitably diverge all the usual problems of project management get exacerbated horribly (in part because what should happen is all the state in Jira gets thrown away as it doesn't reflect reality, but that's a huge sunk cost so no-one does it).
So yeah, I have found that the tool shapes the process, not the other way around.
It would probably work the other way around if every organisation built their own project management tooling around their own processes. But that would be insane.
If you provide a tool that let's managers easily and arbitrarily increase the requirements on their employees, over time they'll continue to do so, because it's a management tool and their job is to manage.
I experienced this phenomenon when I was a designer / CNC programmer. We had a form for requesting a part to be designed and machined. It had a box for tolerance allowance, where the person requesting a part could specify how tight all the tolerances should be, and we had recently added in 0.0005 inches to the options, at the request of a customer. I left for a month to do training at another location and came back to find a ridiculously long backlog of work. The manager who'd stepped in for me had decided that tighter tolerances would make better products, so was selecting 0.0005" tolerance for every feature on every part.
To make up for how ridiculously slow that made the machining process, he tried to micro-optimize work flows, readjust hours, push machine operators to "work harder". He wasn't a bad person, was an okay manager, we'd just given him the option of doing something stupid, and he'd done it then tried to use his managing skills to make it work.
If you give someone the tool to do their job, make sure that misusing it feels hard.
He obviously did not understand what his job as a manager is about.
Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?
It makes no sense and is first and foremost a management and cultural issue. Second a work process issue. Solid third, one of competency. Probably ways below numerous other problems lies the tool.
You obviously needed to be able to set tight tolerances for some work, so… you seem to need the setting on occasion.
These stories just blow wind in my sails!
If you have management like this (american?) you must be measured like crazy - set goals based on metrics that will push things in a direction you see effective.
> Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?
Because the tool allowed it. What you’re failing to grasp is that UI has a massive influence on how humans behave.
People see empty fields and think they should fill them out.
Jira very frequently encourages over-specifying things by the ticket filer (it doesn’t hide fields by default and “helpful” human behavior is to provide as much info as possible).
The second order effect is that the project managers realize they can add fields and people start filling them with data. This is great for visibility without having to poll all of the employees! Except now it’s garbage data because the wrong people are filling in the data or they are bad guesses and inevitably that rolls up into a report that causes problems later.
Jira is a bad tool because it misleads both people and product managers into thinking they can get data from it that they realistically can’t.
> He obviously did not understand what his job as a manager is about.
> Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?
He's not the expert in the field, I am. Normally, I would have vetted the work orders and fixed it before hand. This is similar to managers in the software world, where the team lead or senior engineer would say," No, we won't do that, it's a bad idea". He never should have been exposed to an option that could screw everything up so badly, but I mistakenly left it on the form. He was just trying to fix what he perceived as a potential problem. He was used to making small changes to work orders to save money or get a more refined product.
The biggest problem with our company's structure is that the operators, for whatever BS org reason, don't have the "pay grade" to tell him to pound sand. Managers need to sit below engineers, in my opinion.
> you must be measured like crazy - set goals based on metrics that will push things in a direction you see effective.
In my sector of manufacturing, margins are king (regardless of locale). If you can cut 10 seconds from an operation, or find a tool that lasts 20% longer, you can save tens of thousands of dollars a year, so we track everything.
I'm willing to entertain that the teams using Jira are just making worse choices about the work principles they agree on than our teams using gitlab issues, and that it is coincidental and unrelated to the tool. Surely you agree though, that in general a tool can adversely affect user behavior? The agile manifesto said to value tools and process es less than individuals and interactions, not to discount their impact altogether. Developing software in a single paradigm language when your domain is better suited to a different paradigm is a horrific blunder I have witnessed twice in my career. Developing giant systems using vba macros in excel is a common mistake you hear about. I can however believe that the teams that selected jira over gitlab might have done so because they already bad this use pattern in mind, and not because the tool encouraged it.
many organizations are overwhelmed with inexperienced new graduates; they end up doing what they want or how they did things in college projects.
then they get promoted, and may never learn / experience why a task / defect tracker is not where you store requirements / design.
(note: the above comments are for long lived software only. it you rewrite your web site from first principles every you, do whatever. it doesn't matter)
Bitbucket recently has shockingly poor reliability. Quite often you see nothing on the status page but see other people having issues on twitter. We've nearly migrated everything to github, plus github has better features and more powerful.
They've been doing a large transformation recently to put it on a new platform. Not saying that's an excuse, but it is an explanation for some of the problems they've had.
Then I tried a bunch of their competitors. Still stuck with some of them.
Sadly, some of Atlassian's products - namely Confluence and Jira - are the best in the business.
Those complaining below about PMs staring at JIRA all day... well, this is a problem with PMs, not JIRA, and it happens even if they are using other work management tools. We created a middleman position in our business to deal with the stuff we didn't want to - tracking work, getting requirements, etc - and we must reap what we've sown. They become obsessed with the management stuff because that's why they exist, and they will fill their time to justify their existence.
> Need to run on-prem, it's mostly the wiki-like features I'm interested in.
Since you are looking mostly for the wiki part there is Dokuwiki which is magnitudes better at being a wiki. Remember, wiki is derived from the Hawaiian word for quick or something to that effect and whatever Confluence is it isn't quick.
Don't know how well it will hold up under scrutiny if black hats gets a reason to swarm over it, but unlike Confluence you can hire someone to patch the guts of it if necessary.
Edit: I have no reason to believe it is worse than anything else, I'm just pointing out it probably hasn't had so much exposure to help it harden.
Maybe. But I have a hunch that we are severely underestimating huge parts of the workforce.
I mean: ux discussions often feels like they assume users are a separate species somewhere between ordinary humans and chimps when it comes to intelligence.
I have some experience with training users and I have only given up once.
In my experience, it depends on the industry and company how competent their users will be. I've been a training (back when thinngs were in person) where a user started getting irate because their login wouldn't work to our software. The trainer walked over to see what was going on, and the user was trying to put their login credentials into their bank website instead of ours.
These were sales people.
So often, somewhere right above a chimp is where some of your users are.
I fully agree that you can train users for a lot. But the question is if it's worth doing so in the specific case. And wikis often already have trouble with people not using them enough, making them seemingly hard to use doesn't help.
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data."
"Please don't comment about the voting on comments. It never does any good, and it makes boring reading."
I am considering going with Bookstack Wiki for my company. But I am not a Fortune500 company.
I would say it is very darn complete, perhaps without the syntactic linking that Confluence has.
The only thing missing from it, is a very solid backup and restore method from the admin panel. The authors want users to rely on database backups and file level backups, that must be handled manually. Essentially saying "not my problem".
> The authors want users to rely on database backups and file level backups, that must be handled manually. Essentially saying "not my problem".
Just a note on this, this is something I'd like to build in eventually. It's just that each layer of our own we add upon the underlying methods increase the risk of error in something fairly critical.
A simple command-line based backup solution wouldn't be too difficult to add, but restore and admin-panel usage are more significant challenges once you get into it.
Mediawiki has worked well. I’d be curious to hear others experiences with it.
VisualEditor is an extremely good WYSIWYG interface. The wiki is able to scale well (project sites are unlikely to approach Wikipedia scale). The API is useful. Wikitext editing gives power users a lot of flexibility, though it’s not as popular as Markdown.
Access control & edit-publish workflow options may be too limited for the desires of some project teams.
My company is currently migrating off of Confluence due to the ending of the on-premise license. We found a combination of a simple web-based knowledgebase app for public content and Office 365/Teams -- which we already license.
You could put Cloudflare Access (with Tunnel) in front to shield against exposing the instance directly, I’ve used it in the past for other products that has been good.
Thanks for suggesting BookStack [1]. I did initially create the project as a free open-source alternative to confluence as I didn't want financial approval being a limiter to documentation collaboration.
One of the main things to consider with BookStack is the semi-fixed Shelf > Book > Chapter > Page structure (Where pages have content, chapters & shelves are optional, and Books can be within multiple shelves). For some this structure is limiting, For others it helps drive organization.
I'll just go with "Yes" because we use the same Confluence installation our entire organisation. Spaces might be configured differently, but we can have all our documentation in one system and link across space.
There really isn't that many alternatives, SharePoint maybe, but then you're just suggestion something worse.
Biased but I'm actually building a competitor (V1 is almost ready) to Confluence for medium to big organizations. But I don't understand your requirement for on-prem. That's clearly not an advantage from the security point of view. Apart from Quip, Sharepoint and Confluence (soon stopped) I'm not sure there is any commercial knowledge base tool that are available on-prem. The only thing that you can hope for, is "bring your bucket" in which static resources can be uploaded in your S3/Google/Azure bucket and some managed instance (like Atlassion Cloud) for the app. But on prem is going to be something from the past honestly
Being able to self-host is a hard requirement for many organizations. Especially for tools like a wiki, which may contain proprietary/secret business information.
The last time we reviewed the Atlassian Cloud hosted products, they did not meet our security needs (requirements include isolated tenant from other customers, customer managed keys, etc) though they were much closer than a few years earlier. We also review the general security practices of the company (for example to make sure they implement a secure SDLC and follow other security best-practices).
Plenty of deployments will continue to be on-prem, cloud is not perfect for 100% of use cases.
Example: If you are a semiconductor manufacturer, you probably are not going to be storing all the documentation about your bleeding edge fabs on a cloud provider.
PII, PHI, classified data, controlled unclassified information, proprietary trade secrets, a requirement to host user data in the country the user lives, a company is massive enough to own data centers and may as well use them. There are so many reasons to self-host. Unless your service is as big as AWS/Azure and can afford to build a private cloud in a location of the customer's choosing for sufficiently large customers, "only cloud" isn't good enough for many use cases. You're putting your own convenience as a developer ahead of the needs of certain users. Which is fine, I guess. You don't need to serve everyone. But you shouldn't be out there acting like self-hosting never makes sense. You may as well ask why some facilities have their own generators and their own wells and don't just universally hook into the public grids. Some applications have requirements for hard perimeters and self-reliance.
The issue is that to put company data on your server, we need IT security people to sign off on it. That takes years and a lot of budget, just to get that authorization. It also likely comes with restrictions, like not being able to use it for very sensitive company data or government data.
I personally do not categorize them to equivalent to Confluence, Sharepoint, Notion, Quip, ... but if you do, yeah there are few wiki software which are available on premise.
I'm not trying to promote my cloud offering. I would like to be able to offer self hosting, but we still haven't found a way to do it. This is too much hassle for everyone. There is a tradeoff between ease of use of a software and the security process. A collaboration tool which is difficult to update and thus will not evolve quickly is an issue for its adoption and for its benefits.
Well first its interface, if a non technical user can't user the tool that's going to be a big problem. Confluence has not the best interface but still better than Xwiki. The best the interface the better the adoption as a whole in the company. And for knowledge sharing adoption is critical. That's actually why Notion has been such a success recently. Even though their product is average, people want to use it, because they like the interface.
I don't have the time to do a full comparaison of other features, but wiki tools are in usage very different than collaboration tools. Can you have the list of last consulted documents ? Can you embed external documents ? ... Kind of the same things as Slack vs IRC
>I don't have the time to do a full comparison of other features
That should be your first prio before anyone locks one's information into your system...XWiki can import and export confluence and even wikimedia data, i never use a system when in cant import/export to the the next best product.
Confluence can take text and turn it into a black box format shoved inside a database that you can't edit with a real editor, then shove that text into a black box unstandardized version control system shoved inside a database! Take that, other tools!
Sorry, must have lost some context... nobody wants that if they know what they are doing. I don't want it. I'm saying this is the reality behind confluence. (and I don't like it either!)
So why are they so popular? Because Jira is a wet dream for mediocre micro-managers (of all levels), allowing them to manage by ticket, instead of lead by example.
Atlassian products are some of the worst glued-together garbage in the industry. The entire product surface area is probably rife with exploits.
Using Confluence or Jira will show you just how much Atlassian cares about its own products.
I'd love for this to be the straw that breaks the camel's back and makes IT/infosec orgs move away from this bilge.