Why does High Fidelity not use Jira?


#1

It seems feature requests, project / task management along with bug visibility internally and externally would be better managed in this format? It seems for its low entry cost for a cloud solution it would benefit the overall organization of the project and the collaboration between developers, internal employees and end users in one central location.

Github seems to be the code repository choice which integrates:

https://confluence.atlassian.com/adminjiracloud/connect-jira-cloud-to-github-814188429.html

as well as for paid tasks you could reference ids / links within feature requests category so that people know where to go if a feature request is open and if there is potential money opportunity.

Beyond that I can see it as a great looking glass for us to look at features we want, status / conversation of the work being done on them.


#2

yes, that would be very nice :slight_smile:


#3

For those who arent in the know,

They’ve been using Fogbugz for a while now though, which is a Jira equilevent, and where many of the alpha qa-testers / volunteer-devs been posting bug reports to when not in Github.

Just mentioning that out there. Visibility on it could be a thing they could improve though, which is why I usually report my bugs on both the GH, and FogB.


#4

This is the first time ive heard of this and glancing back at the wiki it not mentioned at all for developers and the forums appears to only mentioned it 6 times in bug comments including this one.


#5

Most of the time its mentioned in meetings in hushed wishpers.


#6

Rather unfortunate, poor project management and collaboration typically cripples projects long term.


#7

Well, they actively do use it. What I meant was in Community meetings, not theirs.
It just not communicated to us.


#8

Would there be opposition to me creating a Jira to collaborate with the community more effectively?


#9

usually thats handled by the Git Tickets though. They usually had labeled the stuff, but now that it is december there isnt that much activity on them.

Id suggest just putting them to what they use instead of fragmenting all the possible places more.


#10

Sorry I hadn’t seen that before. I’ve had two big complaints about Jira, that I still think matter a lot. We used it at Linden Lab and I was pretty unhappy with it, looking back:

  1. The page loading performance is so bad that it discourages use and makes browsing through many issues quickly impossible. It often takes 15+ seconds for a page refresh to occur when there are a lot of issues in the database. I am a big believer that compile time and site responsiveness are key drivers to throughput, so I am very negative on using solutions that are not responsive.

  2. The high complexity of the formatting with the large number of entry fields in issues makes Jira useful for very sophisticated editors but daunting for a more casual user who just wants to report a problem. So I can see it becoming something used by a few hardcore editors but ignored by people who have less time. I’d like to use something that is inclusive for all.

I think github issues achieves the goal of being fast and easy to use, but admittedly lacks data that could help with prioritization and tracking. I’m willing to try out the latest jira if there is a good example of a public site with 1000+ issues that I can try for both speed and look.


#11

This! It was hell trying to search for related issues to bugs I reported when I was in SL. This ended up in duplicate bug reports and stressed out devs. I am not a JIRA fan.


#12
  1. I don’t have any external samples you can see as the ones that I engage with at that volume are private Jiras using specifically Jira cloud and not the old open source jira license which is what I believe SL and firestorm still use to this day, which i agree feel like they are running on a potato. Though with the cloud ones I use both personally and with larger projects I engage with response times are reasonable. I would wonder what the difference of their large customer list such as twitter, visa, nvidia, etc have going differently than SL that made the performance difference, as I can’t imagine they are just putting up with it at their larger volumes. Jira core is public this might role model it better for you? https://jira.atlassian.com/projects/JRA/

  2. I agree on this and ive seen this one addressed differently. Some prefer to have a webpage that dumps a bug / feature request to the jira using an API so it integrates with their custom helpdesk solutions. Others have minimized entry to ambassadors and leave development viewing as read only. Ive even heard of other corporations tying it into Jira Service Desk which itself is a whole other customer support system for FAQ and issue lifecycle tracking.

I think its pretty much agreed that it should be fast, anyone should be able to jump in and see where things are at as a status (even features requests) so they can make a few decisions and answer questions as a community (Is this being worked on? Has this been suggested? Can I contribute anything to this ticket (advice, code, etc) Has my bug / issue been noticed?) I think ultimately this tracking through the rapid development of a community / corporation project provides a large scope of opportunity for us to work dynamically together without having to have the team right there with us on demand.

** side note***
I mentioned it to others regarding Jira and I am willing to offer help getting it rolling for HF using their cloud services if its a matter of resource / experience.


#13

The Firestorm Viewer JIRA for Second Life.
jira.phoenixviewer.com

Server instance (not on the cloud).
30,282 user accounts.
32,203 total issues (some are internal issues you cannot see, plus we use this JIRA for support tickets too).

Imo JIRA is the best bug tracking software there is, but maybe I’m biased because I’m the JIRA admin :laughing: