To be fair, this has unfortunately been a constant theme with recent policy changes: the general membership (and even (sub-)division staff, to a large degree) is completely excluded from any discussion with the new/revised policy afterwards being presented to them as a fait accompli with little to no willingness on the side of leadership to make any further changes for the time being - usually with way too little time to implement all necessary changes and/or inform at least the majority of the membership by the time it becomes effective.
In the new CoC alone, there are so many seemingly arbitrary, unnecessary, or overly restrictive changes while other things that are regularly causing issues on the network are not being addressed - and don’t even get me started on GCAP or TVCP…
- The definitions section does not include a definition what an “account holder in good standing” is, but instead defines a bunch of basic English vocabulary such as “not” or “may”.
- A4(c) would really have benefited from a change to give actually useful tips on how to inform ATC that you are a new user because the last thing you’ll look at as a controller is the name the person logged in with; many places (at least here in Europe), however, have ways to check item 18 of the flight plan for words like “new”, “newbie”, “rookie”, etc. and then automatically display an icon above the tag to indicate when one of these words has been found - and of course adding a quick “new pilot” or similar to your initial call with a new station would invariably convey that message to ATC.
- A12 would have benefited from some form of description what types of callsigns/identifiers are being talked about
- A13 would certainly also have benefited from additional clarification, seeing how the question whether certain types of operations or aircraft are permitted crops up once or twice every week.
- A14 should also have been updated. Particularly in the increasingly busy areas of the network, it’s becoming more and more of an issue to provide equal service to text pilots. It really should have been clarified if controllers are expected to always provide equal service to text pilots (and as a consequence log off if they are not able to do so) or if it is permissible to, e.g., put a text pilot in a hold somewhere until voice traffic numbers have reduced to a point at which the additional workload of controlling via text can be accommodated. Likewise, a note to inform pilots that text communications are a significant increase to controller workload certainly also wouldn’t have hurt here.
- B4(b) is really unfortunately worded. On the one hand, it uses “should” which makes the entire rule a suggestion and thus technically makes it permissible for pilots to arbitrarily change their squawk, on the other hand it doesn’t acknowledge cases where pilots are required to change their squawk without being instructed to do so (apart from changing flight rules, although at least here in Germany, you still have to get an appropriate instruction from ATC before you are allowed to change your squawk code), such as squawking 2000 30 minutes after entering NAT. A wording along the lines of “A pilot shall maintain a previously assigned squawk code unless otherwise directed by ATC or a procedure” would have been more apt.
- B5’s interpretation relies heavily on how the word “or” is interpreted (both an inclusive and an exclusive interpretation of “or” are possible, as is so often the case with this word). I assume it is meant as an exclusive or, i.e. pilots have to figure out whether there is a designated advisory frequency and only if there isn’t use 122.800; however, it would also be perfectly reasonable to read it as an inclusive or which would allow pilots to use 122.800 everywhere at all times while not under ATC and make use of a designated CTAF optional. With how many complaints about pilots being on a bunch of different frequencies since the start of the CTAF trial, B5’s wording should really have been revised to something unambiguous.
- B7 could have benefited from clarification whether ATC can dissolve a formation whenever or only when the formation is under ATC (e.g., what about a VFR formation in airspace E or what about an IFR formation in airspace G?)
- B2 and B9 should have been made consistent. Why are pilots not permitted to just pause in Unicomland as long as they ensure they “do not cause any disruptions to other account holders”? Or the other way around: why are pilots permitted to use time acceleration/decelaration in Unicomland but have to disconnect if they want to pause? To tie into what the companion document for the current CoC says in regard to B2: How is it any more difficult to gauge who pilots may affect and how when pausing compared to using an acceleration or deceleration function (especially when considering that deceleration functions may well have the exact same effect as pausing the sim)?
- B10, similarly to B4(b) doesn’t acknowledge real world rules. There are many cases where VFR flight plans are required IRL, yet the CoC doesn’t compel pilots to file a flight plan in these cases, while on the other hand requiring users to always file a flight plan for IFR flights even though there are various places where IFR flights are not required to file a flight plan in some cases. A wording more along the lines of “All pilots shall submit a flight plan before their flight if required for the planned flight” (there’s probably a better way to word this, but you get the gist) would definitely have been an improvement.
- B14 seems a bit out of place as a separate rule - I feel like it would have made more sense as B8(d). However, my main point of contention here is that pilots not having the latest AIRAC has rarely been a problem. Unless a pilot is using ten years old nav data or procedures at a given airport/structures in a given airspace have recently seen a major redesign, it has usually been possible to find an adequate alternative solution - provided the pilot communicates this, of course. While I welcome the idea behind this rule, I feel that it could have been made less restrictive to pilots who may not be able to pay for a Navigraph subscription to keep their nav data up to date at all times (sure, MSFS2024 will always use the latest nav data, but not everybody will be using MSFS2024). I feel like a rule similar to B6 may have been a better compromise: permit pilots to use out of date nav data, but require them to disconnect if ATC can’t accommodate them without the latest procedures, as well as requiring pilots who are using outdated nav data to check beforehand if there are procedures they are not able to fly and inform ATC accordingly in advance.
- C8 still heavily restricts the vis range for ADC positions, particularly DEL and GND. In many places throughout the world, the primary task of the Delivery controller is not to hand out the enroute clearance, but to manage the outbound flow of the airport based on current operational restrictions and, importantly, the expected amount of arrivals. With just 20 NM vis range, this is effectively impossible as you may not even be able to see the entirety of the final (thus, when we are fully staffed with two Delivery controllers, one exec, and one planner, the planner will connect with a Tower suffix to be able to use a reasonably workable vis range). Raising the vis range for DEL - and for top down purposes also GND - to be the same as for TWR would go a long way in ensuring DEL can plan an appropriate outbound flow to reduce delays and complexity.
I know that for at least some of these points, the current and presumably also the upcoming updated companion document already provides the answer/clarification/specification, but the companion document is - to my understanding - not required but just optional reading, so anything important for the interpretation of a given rule should not be found only in there; instead, the companion document should only add additional context or give insights into the reasoning for the existence of a given rule. If I’m wrong and members are indeed expected to know the additional details put forth in the companion document, I would have to wonder why we even need the shortened “normal” CoC.