[new_here]

Zepel looks great, a much cleaner and more pleasant experience than JIRA. Everyone uses JIRA because it's become synonymous with agile, so companies purchase and use JIRA to show that they're agile. In practice though, JIRA is ridiculously cumbersome and slow. It's time for it to be challenged.

If you can market yourself as a simpler and faster way for agile teams to run projects, and deliver on that, then you'll probably get some decent traction with SMBs and work your way up from that. Make teams feel like they'll be agile by using Zepel.

Great work and good luck!

[msla]

The thing about Jira and Confluence which annoys me most is the fact it's possible to have useless combinations of permissions.

For example, in Confluence, there's a nested structure: Pages exist in spaces. Pages can have more restrictive permissions than the space they're in, so you can have a space with pages anyone can edit and pages only a select few can edit. Now for the annoying part: It's possible to have permissions to edit a page in a space without permissions to view pages in that space. Does the special permission override the general? Does it, Hell! Of course not! That set of permissions is useless, in that it doesn't allow you to do a damned thing!

It would be great if Atlassian packaged a sudo plugin with their software, so you could see what a given user could see and figure out what's going wrong. It would be great if Atlassian packaged an auditor in with their software to, at the very least, alert you to useless permission combinations. I know the first would infringe on one or more paid plugins, so that's not going to happen, but I don't think anyone has anything which solves the second problem.

[probius]

Although it's not packaged together, you can download this sudo plugin: https://marketplace.atlassian.com/archive/12730 and it should still work on the latest version of Confluence.

[spullara]

Most flexible permission systems have this issue. See every database system and your filesystem.

[atonse]

That’s funny that people get JIRA to associate themselves with agile methodologies because theirs is one of the worst tools for it (in that the UI is this confusing herrendous mess). Whereas Pivotal Tracker feels a bit too “purist” in the other direction. Maybe this tool will feel somewhere in the middle?

[dragonsh]

Try Taiga [1] [2] truly open source beautiful system supporting both kanban and scrum style development. It's very intuitive with beautiful cards based interface. It also support user story point poker to assign story points.

Indeed it can be projected directly on a wall screen to see a kanban board in real-time with customizable details.

Also with easy plugin system, it can extend to integrate with other system in company to automate various processes or customize to once liking.

[1] https://taiga.io/

[2] https://github.com/taigaio

[e12e]

Looks interesting, if a little convoluted to set up for self host? A couple of outdated docker-compose third party projects, and official script that is in alpha and depends on vagrant..? Maybe the most sensible is cloudron - also unsupported?

[dragonsh]

Their guide [1] is step by step and very easy to self-host. Indeed in our place we started using it with very early version and moved to new version without any issues.

We use LXD container and launching is as easy as:

   $lxc launch your-pm-1.0 yourpm1

Everything else is just automatically configured.

[1] https://taigaio.github.io/taiga-doc/dist/

[johnx123-up]

Or, perhaps, Restyaboard?

[Arubis]

I previously worked on a team that used Clubhouse (clubhouse.io) to find this balance, and it was demonstrably excellent—to the point where I almost wish I hadn’t been exposed to it, because it’s made dealing with Jira that much more painful.

[vasco]

I use JIRA cloud every day and have for almost 4 years and it's never been slow. Is your company using JIRA cloud or hosting your own?

[nemothekid]

I can only imagine you are being a frog slowly boiled to death.

JIRA (and confluence) are the slowest web apps I’ve had the pleasure of using. Simple navigation takes seconds when bouncing through pages. Accidentally clicking the wrong issue is physically painful. When I think JIRA I think glossy silver spinners.

[andy_ppp]

I'm not sure how we can possibly be using the same website.

[mrunkel]

You're not. Jira is run over many different servers. I think that accounts for a great deal of the difference in experience.

We self host Jira and it's not slow for us.

[andy_ppp]

I've just timed it on a bug detail page - it takes 7.8 seconds to complete with janky loading of different sections/data. I find it impossible to believe this is server related - looks more like they have terrible frontend code.

[new_here]

Agreed, it takes on average 5 - 7 seconds per page load from our office with a good connection in central London.

[veidr]

We are using JIRA's cloud offering and it's the slowest application I use. It's slow enough that I don't care about any of the other (pretty glaring) UX flaws.

It often takes more than 2000ms to switch views (e.g. just to switch from looking at an issue to the board showing list of issues in the current sprint for my team). Sometimes, 5000ms plus.

It's so slow that I've noticed everybody does what I do, namely ⌘-click all links so that they open in a new tab. That way you don't "lose" what you are currently looking at, and have to endure another 2000ms load time just to see it again.

Everybody's JIRA window has like 40 tabs open by the end of the day.

One result of this, beyond being irritated, is that meaningful bug discussion never happens on the ticket comment threads, the way it used to with GitHub Issues, or the way it would happen if JIRA was as fast as a normal app (like, say, GitHub Issues). The discussion is all on Slack now, completely separated from the issue tracker and super hard to find when you need it.

I occasionally manage to paste a few Slack links into JIRA bug comments, since I already have that tab open and I know nobody else will.

We didn't love the feature set and UI of GitHub Issues, either. (Hence the sadly failed search for a new tool that resulted in JIRA.)

But it wasn't slow, so people did actually use it. I don't think we have a features/UI problem with JIRA. If it was fast, I think people would use it about the same as they did GitHub Issues.

But it is slow, so engineers use it very minimally: create an issue (which is usually done via our Slack chatbot, because using the JIRA UI is so annoyingly slow that somebody wrote a bot to automate that), put the issue into a sprint, and then close an issue when it is finally done. Those are the 3 operations we do.

I think the project manager people are OK with JIRA, because they mainly use it to generate fairly complex reports that admittedly are pretty useful to see how we did in the past iteration compared to our goals. That is SUPER SUPER slow too, but they don't mind as much because it's a bi-weekly thing they do, not something they do over and over throughout the day.

I think JIRA has a variety of other usability problems, but the deadly slowness outweighs all of them combined. We still "use" JIRA in the sense that it's the system we use to track bugs. But we don't actually use it much at all — because it's slow.