Hi all, 18 year member of the VATSIM community here. Over the years the network has grown immensely. My question would be, is there ever any talk about changing the top down philosophy? I think the controllers at times are over worked. They are controlling so many airplanes they’re not supposed to control, they can’t control the airplanes they are supposed to control. For example, if I’m flying out of KMIA and the only controller is MIA CTR, I have to contact that control. But the problem is, the controller is giving instructions to airplanes in the air AND on the ground. They’re also handling two other major airports(KFLL and KTPA) along with other airports. I guess my point is, shouldn’t the “center” only handle airplanes above a certain altitude? They shouldn’t be giving clearances to airplanes in Ft Meyers.
I don’t think so it will change. As per GCAP controllers shall provide top-down service when traffic levels permit.
If him controlling other aircrafts on ground affects the other pilots experience/he can’t handle it, then he has the choice to send them to unicom.
Hello, please refer to part 4.6(d) of the new Vatsim Global Controller Administration Policy
If a controller finds themselves overloaded by traffic, they are permitted to provide a reduced service to pilots controlled top-down. In extreme cases, withdrawal of topdown control from an airport may be required; however in such cases controllers should consider whether logging onto a smaller/split Position might be more suitable.
wait, am I seeing this correctly that they updated GCAP already but did neither provide any information that there was an update at all (apart from the incremented version number) and also did not highlight what exactly was changed (at least changebars for any new/changed/deleted parts would have been nice, especially considering that the previous version is seemingly no longer publicly accessible)?
You mean, other than the 5.5 months’ notice that was published on all of our social media platforms, including this forum? 
Never mind that the Regions and Divisions had been working on this most recent draft for over a year before the draft was published last September.
So, this should really be no surprise.
And, when a policy is completely rewritten, there would not be change bars, as they would be needed on every line… However, the revision record very clearly states what changed.
I think what was meant here is a change within gcap either shortly before its introduction or after, because there were quite some discussions in discord about this exact part about dropping service in overloaded situations missing in gcap shortly before gcap came into effect, so it is not about gcap coming into effect but uncomunicated ghanges within gcap versions in the last few weeks
Thanks, Louis. I read the post in a different light, and can certainly see your interpretation. I appreciate the clarification.
OK, maybe I’m not completely following the concern.
The updated GCAP, which was coordinated with all the Regions and Divisions, was announced and provided to everyone in September.
There was a discussion in late January and early February about a concern for additional considerations for top-down on the forums and Discord but not made through formal channels to try to influence a positive change in GCAP before it was released.
However, the BoG was astute enough to see the discussion, realize that it would be smart to make a small change to accommodate the concerns that were raised in social media, and worked quickly to incorporate an improvement that would satisfy the concern prior to the effective date of 01 March.
Now someone is complaining that VATSIM was agile enough to agree with a concern and implement an improvement to a policy before its effective date?
Or one person is complaining that he didn’t hear about that last minute change from his subdivision, and instead of asking his subdivision leadership about whether or not they communicated the change, complained to the Global VATSIM community insinuating that none of the Regions or Divisions communicated the change?
Apologize if I’m missing it – it’s early and I haven’t had my coffee yet.
No, im absolutely not complaining about agile changes in vatsim regulations, quite the oposite, I was positively surprised to see this change, it would just be nice to have a quick announcment on such revisions on the forums, or on discord or something.
And first I thought it wasnt even in the document revision but I didnt read carefully enough, it actually is in there.
Like Louis, I’m not complaining about the change per se and indeed think that the addition of 4.6(d) is sensible and helpful. After all, I was part of the group who pointed out how problematic the original phrasing was with regard to reducing/dropping topdown service during high workload outside of events for which this was specifically approved by the vACC.
What I am calling into question is the communication of this change. A short message along the lines of “there has been a small update to GCAP” in the appropriate announcement thread or something like that to make sure that people have a chance of noticing that there was a change, no matter how minute it may have been, particularly as this is a change that affects all controllers, wouldn’t have hurt.
To draw an analogy with GCAP itself here: it’s like if we made significant changes to an SOP without putting out a notification to our controllers that a change took place, but expected them to know. For good reason, GCAP prohibits that (or at least that this could result in consequences for controllers). In the same vein, I think it’s very much reasonable to expect some sort of notification on the network level if a network-wide policy is changed. And that way, individual vACCs could still do a separate announcement for their own controllers if they deem it necessary.
I do retract my statement that the exact changes weren’t highlighted. Similarly to Louis, I initially overlooked the relevant note in the revision records. I’m personally used to the revision records in these types of documents simply noting when a change took place and who authored it with the concrete changes then indicated by changebars throughout the document and - if necessary - the availability of an archive to make a comparison with previous versions. This is certainly no excuse for missing the note and subsequently making a partially erroneous statement, but the fact that both people in this thread initially overlooked that part could indicate the benefit of making the exact changes more visible somehow.
Out of all the communication problems within the VATSIM hierarchy/bureaucracy that I’ve seen in recent months, this is certainly a minor one, but it’s nevertheless something that I think should be taken into consideration for future policy changes because a lack of communication is always problematic and backroom discussions and agreements have a tendency to produce suboptimal or even bad results; this is an aviation community - communication and openness are at the core of aviation and even more so of VATSIM whose primary focus is to introduce the communicative element of aviation to flight simulation. Why not carry that into the decision- and policymaking process as well?
Absolutely. Always room for improvement. Many thanks for the feedback.