Forum communication

From FlightGear wiki
Jump to navigation Jump to search
Working together
The project as a whole:
Users and feature requests:
Communication:

So you have a problem with installing/starting/using FlightGear, and someone pointed you here. Please take the time to read on. This article will explain how you should ask for support, and why.

The "support team" includes you

FlightGear doesn't rely on sales or license fees. FlightGear relies on having a base of contributors volunteering their time. This base includes the users, but in order to contribute, they need to be able to see something that bothers them not as something to complain about but as something to be investigated, understood and fixed.

Why?

FlightGear is developed by a fairly small community of volunteers, most of which enjoy understanding complex problems and fixing bugs. This community seems to be mostly comprised of "geeks", i.e. people using powerful gaming hardware, and Unix-based operating systems like Linux. This means, unfortunately, that newer features get tested on a very small variety of platforms that can't cover all of the end-users' cases (especially older Windows versions). Sometimes new features are only really tested once they're released, or once they're enabled by default.

Don't expect your problem to be obvious, actually it could very well be unknown. It's very likely that only few people, if any, have already reported your issue, or even experienced it. In fact, very often such issues are highly setup/system specific and depend on the type of hardware, operating system, drivers, settings - and sometimes even other software installed/running locally. All this is further complicated by the fact that unlike MS FSX, FlightGear is cross-platform software, which means that it needs to run across all supported hardware platforms and operating systems (Windows, Mac OSX, Linux).

Note that the fact that a bug is rare doesn't make it less important, but harder to solve for the lack of (good) data. In an open-source project like FlightGear without any funding, the developers depend on end-users to provide good feedback so that they can identify, troubleshoot and fix such issues. And they're grateful for everybody providing this very feedback in a constructive and helpful manner.

Troubleshooting is a hard job

Remotely troubleshooting problems is an extremely tedious process, however that gets more tricky because of people's tendency to act in a frustrated and sometimes even disrespectful way when reporting such problems.

Unlike a commercial software project, FlightGear has no funds to invest in development, QA testing or support for end-users. Commercial software companies will typically have dedicated teams testing new features across a huge variety of hardware/OS configuration.

The quality and timeliness of feedback

Lacking of resources, FlightGear depends on end-users providing good feedback to ensure that it keeps working for most people. And for features in development it also depend on timely feedback, too - given that developers are volunteers, they need sufficient time to troubleshoot and understand a bug, but also enough time to fix it. Preferably, several months prior to a release, not just during the few weeks shortly before release.

While the community have been providing a way for end-users to get involved in regularly testing FlightGear pre-releases provided via the FlightGear Build Server, very few users seem interested in getting involved in this, and even fewer people are actually providing bug reports via the issue tracker, unfortunately, so far.

This is why you need to be the developers' eyes and ears - they cannot see what you're seeing, and they cannot know what you have done.


About making an effort to communicate

Cquote1.png Aiming for proper spelling is also a matter of politeness. In the age of spell-checking capable browsers, leaving all your spelling mistakes in is in essence signaling 'I don't take the time to compose a decent post'.
Cquote2.png
Cquote1.png often people are interested in getting the word out over communicating. It's the equivalent to always talking and never listening in a face to face situation. And this leads back to Dunning-Kruger - since they think they already know everything relevant, why should they listen? It rather should be anyone else who needs to listen.

 Cquote2.png
Cquote1.png correct spelling shows politeness. Nobody expects perfect spelling. But if you fail to demonstrate that you've put at least some effort into your post, why should anyone make an effort and read it? Or even answer it? I reckon for the forum to be useful, one should aim at being understood, rather than just getting the word out.


Also, if you want to reach the experts -- you can be sure they read a lot each day. Since reading a text with poor spelling is much harder, you chances of getting heard decrease rapidly.


Cquote2.png
Cquote1.png I have to agree with the other guys. I'm not sure if "polite" is the best word to use, but it shows that someone is making an effort. If you make the effort to spell correctly and use terms correctly then you're likely to make the effort to listen and analyze the information you're given in return.


When posts are written with a lot of spelling and grammatical errors it makes the readers wonder just what person they're dealing with. Fine, if a person has dyslexia it typically shows actually, but if they don't then it really does come off as someone who just don't care about language and therefore not about communication. So why go through the effort of communicating with them if they don't care.

I'm not saying style is more important than substance, just that some people have encountered enough poor style covering poor substance that they react when they see poor style again; because statistically it's likely to contain poor substance. It's a "tricky" situation: You either make an effort to try to communicate with people in a way that furthers the discussion or you double-down and do it your way. In the case of discussing technology language is very important and we have a "neutral" one that everyone can use, just as everyone can use neutral and proper English. I see no reason not to make an effort to do so. I think we have enough crappy social media outlets for trite low-brow commentary.


Cquote2.png

When the frustration kicks in

Misunderstandings may arise during a forum discussion. After all, most people here aren't native English speakers. But fighting on the forums is just a huge waste of time and energy. That time is better spent on what our developers enjoy: creating software and new features. They are willing to help if provided with enough information on the problem at hand. Otherwise they wouldn't hang out on the forum. And they are not getting paid.

Voicing Opinions

Cquote1.png Of course everyone is entitled to have an opinion about anything, and also (within limits of politeness) to express that opinion, to dislike certain things and to request changes. That's not under debate - the question is very much one of how.

If you make a public statement 'feature X is broken', that's pretty much forcing the attention of the maintainer to your post (unless he accepts the public perception that feature X is indeed broken and he doesn't care - which many of us don't do, because we do care to deliver decent work). And it's a statement of fact, not of opinion. It's not that you don't like how things are personally, it that you claim they're objectively wrong. It's the equivalent for crying 'Fire!' - the fire brigade will have to come then.
Cquote2.png
Cquote1.png But, if you call the fire brigade without reason, you'll see a harsh reaction. In reality you will often have to pay a fine, and in FG, you'll be considered a time-waster and an ignorant person if you call things out as broken just because you don't understand them properly. Because just as the fire brigade doesn't enjoy being called for nothing, developers don't enjoy being forced to react to some non-existent problem and to have people imply that they'd be too stupid to get it right.

But the reality is tricky. More often than not, the problem is sitting in front of the computer screen. I've had an autopilot going mad on me, crashing the aircraft. The reason turned out that I hadn't read the manual, which said quite clearly the AP needs to be handed a well-trimmed aircraft, I wasn't aware of that and handed a badly trimmed aircraft over and got what I deserved. The AP was doing what it should have been doing. In another case, I tracked a malfunctioning AP to me having activated auto coordination, which the AP could justly not deal with.
Cquote2.png
Cquote1.png Frequently a seemingly straightforward issue is not. Menu texts becoming invisible if ALS is turned on seem like a no-brainer - ALS must be at fault. Except it's not. ALS doesn't ever render menu items, and ultimately the thing was tracked back to an ATI driver issue - it occurs on ATI cards only, and also on other OpenGL applications outside FG, and ALS seems to trigger a resource scarcity somewhere the driver can't deal with gracefully.

Personally, I make damn sure I have plenty of evidence before I call something broken. I have called shader code inefficient in the past - that was after going through it for two weeks and coming up with a patch to demonstrably speed things up. That's the level of evidence at which you can feel entitled to call something broken.

And if you don't have the evidence but still feel something is not how it should be - you can ask a question. It makes a world of difference to ask 'I have a problem with feature X - I get this, that's not what I am expected, can somebody take a look please?' rather than state 'X is broken and needs being fixed asap'. Nobody will call you ignorant for asking a question - but making a statement of fact when you're not in possession of the right facts - that's the definition of ignorant.
Cquote2.png
Cquote1.png Many people don't even mind getting and answering feature requests or suggestions if they come in a polite way and with background info. Several additions to AW came out of mails 'I would be interested in a feature XY because I want to do Z, and right now the problem I'm facing is YXZ, do you think we could do that?'. I don't mind spending some time for someone who's interested in something, has some background knowledge and is interested in discussing the how. But I do mind spending my spare time for rude demands after somebody cried 'Fire!' to get my attention.

So, the idea is not to tell people off for commenting about things, or for asking about things. But if you don't have the knowledge and make statements of fact as if you do, that's going to be exposed, and if that feels uncomfortable, you have no one to blame but yourself. If you lie and others expose you, they're not rude, they're justified in doing so. If you feel you need to comment about technical re...on't like something, that's not the same as something being broken - one is a statement of opinion, the other a statement of fact - so why not keep these apart?

Likewise, if you are a paying customer, you can demand a service for your money. If you're not a paying customer and want a service, it's better to ask nicely. Just like you would in real life.

It's actually sad that I have to point out these differences. It should go without saying that if one doesn't really know, one makes careful statements, and if one was wrong, one apologizes for having claimed something false. It's a mystery to me why so many people think the rules of how to interact with each other in a friendly and professional way are suspended online.
Cquote2.png

In conclusion...

Remember: you're the one having a problem with FG. You're asking for help, and you're not paying for the service. So,

  1. Be nice.
  2. Don't blame anyone.
  3. Try hard to provide the information you are asked for.
  4. If you are pointed to, e.g., the wiki articles, carefully read and try to understand them.
  5. Work through any suggested steps to troubleshoot the problem further.
  6. If you hit any roadblocks, tell exactly how far you proceeded and where you needed help.
  7. If you are not sure how to provide good feedback, better provide as much info as possible - i.e. through screen shots or Youtube videos.
  8. Don't expect immediate responses, sometimes it may take a few days to get back to you, especially during busy times (release preparations).
  9. Try to be respectful, deal with others the way you want to be dealt with.

You may of course disagree with someone who is most likely way more experienced with FlightGear than you are. But more often than not you'll be wrong.

Keep in mind that there's really only a handful of people on the forum who regularly provide support to newcomers, those are usually also the most knowledgeable people - and unfortunately, those are also the ones who are most likely busy with other aspects of FlightGear. It isn't uncommon that really tricky issues can really only be understood by people involved in developing the original feature, but those people will have little time to respond properly (if at all), and may also not show much courtesy when dealing with your issue, because we're really just trying to understand and fix problems, not trying to provide top-notch end-user support.

Further reading

Retrieved from "https://wiki.flightgear.org/w/index.php?title=Forum_communication&oldid=73485"