The new Guild UI and Permissions...yikes (Part 1)

Just popping in to totally agree. The guild changes are a change I personally could have done without. I can't possibly go through and make a public note for everyone, and making everyone an officer is not going to happen. C'mon Blizz...
08/09/2018 11:32 AMPosted by Beteljuice
People keep saying that Bliz WANTED to nerf guilds and force their players into the new communities concept (which is still in its infancy and unsurprisingly clunky as it awaits the inevitable improvements). If we want any hope of continuing to enjoy this game, we must assume that Bliz is not simply acting as an evil empire looking to ignore as many players as they can. As a software developer who has lived through several of these disasters at various large companies, let me present an alternate timeline for how this all happened:
1. Bliz game designers listened to users, and proposed the new Communities functionality to allow cross-server groups of like minded people.
2. The scaled-back Communities interface was designed, and someone decided that there are synergies with the Guild functionality.
3. Some gung ho coder saw that there were a number of flags for various permissions in the guild data. Since each flag requires data space and maintenance overhead, they proposed that all the flags could be replaced by an IsOfficer flag, simplifying the code measurably.
4. The proposal was OKed because the people who should have analysed the ramifications in much more depth were busy with the thousands of other changes in BfA, and didn't think of all the scenarios where the granularity was necessary.
5. The code and database changes were made, and the data was converted into the new layout. Not enough noise was made soon enough in the alpha and beta to get it reverted before it was too late.

This brings us to the prepatch. GMs suddenly realize that they have been cut off at the knees. There is massive backlash (although I suspect that GMs make up maybe 1% of the player base, so what we consider massive is less so to Bliz). However, reverting the flags would require a database change to put back the fields that are now history. A solid rule that smart companies follow during software upgrades is that you NEVER make a database change at the last minute, because it can cause way more damage than you can imagine if anything goes wrong. Thus, I think Bliz is truly listening to us but can't do anything until the first post-patch. Fixing things like this in a hotfix has probably been the root cause of major fiascos in the past, so no amount of yelling or pleading will make them risk the other 99% of their user base, and they will fix this when the expansion is out and relatively stable. My biggest frustration right now is that I don't see the downside of Bliz admitting they made a booboo and explaining that the will fix it "soon", other than the fact that the discussion would undoubtedly immediately turn to trying to name and shame the programmers, which would be misguided.

All that said, add me to the list of GM that are insisting this change be reverted since it is really screwing up my vision of how my guild should work, and causing my guildies conniptions as a result.


Except:

They are making changes this patch cycle that damage all parts of the game for no reason.

1. The removal / change of the permissions for Guild Masters.
2. The removal of Loot Master rather than replacing it with a system that allows guilds to still do lootmaster in groups that do not break the amount of pugs allowed meaning - pure guild groups would still have it - anytime you have a group with more pugs than allowed it would go to personal loot.
3. The removal of Auto Accept in the LFG tool.
4. The replacement of the original Guild Roster panel for the Community Panel, knowing that one serves the Community UI concept more than the Guild Community concept. (The fact that the Guild UI had a smaller footprint and presented more information is also something that you have to consider they basically forced the Community UI on everyone.
5. The breaking of Addons that make grouping easier.
6. The fact that there are tons of bugs with the Community UI panel that basically was put into play when it should have been added later on after enough people tested it, maybe even after this expansion was released.
7. The forced use of a voice application - running in the background all the time - rather than including a DISABLE function like they did previously.
8. The addition of new link technologies to invite people into a Community when Looking For Guild could have used said technology to allow people to get invited when they are OFFLINE.

There are plenty of instance where Blizzard plans with this expansion do not match what we expect or what is good for the community as its been throughout these years.

The fact that we as a community are seen secondary to their own plans for the game means a lot and its disappointing.

I can understand changes to game balance, I can understand cool down changes, I can understand stat squishes, and talent changes, but the much bigger meta game shouldn't be changed without considering the damages done.

Consider PVP and Warmode it was basically talked about for at least two expansions before it was released as it is, and it works brilliantly, but still there are people who aren't happy with it.

Consider their policy about "flying" or "no flying" in reality you get a much better game when you have flying because you do not have facades in the game (fake buildings) you have to actually make the terrain and buildings rather than just piecemeal it, but the counter argument to that is people fly over the content they provide. Well damn then they fly over it they should be able to do what they want and play how they want not be nailed to one path only in an immersive environment.

All of these things point to one thing, there are people in the company who do not appreciate their users, who feel that the overall game is something that they have full control over no matter what, and their player base is not entitled to any say.

If it continues like that though sooner or later the game dies, you don't want to allow your users to dictate everything but you need to give a little bit and allow the game to grow in its own fashion, like a child growing into an adult.

The permission changes need to be reverted - simple as that - they damage a part of the game and communities in the game for no reason what so ever.
08/09/2018 02:00 PMPosted by Greenstone
Except:

They are making changes this patch cycle that damage all parts of the game for no reason.


Oh I totally agree, but in most of your other examples, Bliz has pointed out their reasons for making the change. Many people might not agree with the reasons, but the current game designers feel that their new improved vision for the game (which changes every expansion, or whenever they change designers, whichever comes first) have a goal and are making changes toward that goal. That is their prerogative. However, not once have I seen them state that they want to nerf guilds (the removal of guild perks does not count - they realized that it was FORCING people into guilds, so they got rid of it). Thus we have to assume that this is a mistake and will be changed, I just wanted to give a theory of why it won't be changed NOW, no matter how dumb it looks.
Again I suggest you put in a HELP > SUBMIT BUG ticket:

"As a GuildMaster I would like to point out that the changes to the permissions for guilds are broken, we lost too much granularity, can not make ranks the way we want to anymore. The "IsOfficer" rank is too broad we need more control over ranks. Normally officers other than the guild master do not change the guild info, officers have different jobs, recruiting or run raids or deal with mods for gear. You also took away the mute ability, so now we are forced to kick players who disrupt the guild."
08/09/2018 11:32 AMPosted by Beteljuice
4. The proposal was OKed because the people who should have analysed the ramifications in much more depth were busy with the thousands of other changes in BfA, and didn't think of all the scenarios where the granularity was necessary.
^This is what I'm sure was the source of the problem. Not fully thinking through the ramifications of the change.

And I'm equally sure you're absolutely right about this not being an easy, quick fix. They can't simply "revert" it; they have to write new code.

So, what we have to continue to do with this thread is to point out why the current changes don't work, and highlight changes we'd like to see.

I personally would like separate permissions that can be given out by the guild masters as they see fit to as many different officer ranks as they need. A tiny guild like mine doesn't need a bunch of officers, but a large guild with multiple raid and/or PvP teams most certainly does.

Every guild has it's own personality and way of doing things, so we need flexibility on how to manage them. It might seem more time consuming to have every permission require a separate checkbox, but once a GM has set up their ranks and associated permissions, it's super easy. Certainly far easier than the complications the current one-size-fits-all permissions have caused.
/thread
08/09/2018 02:18 PMPosted by Fumel
Every guild has it's own personality and way of doing things, so we need flexibility on how to manage them. It might seem more time consuming to have every permission require a separate checkbox, but once a GM has set up their ranks and associated permissions, it's super easy. Certainly far easier than the complications the current one-size-fits-all permissions have caused.


This.

Revert the changes!
Gonna be honest Blizz. I'm not the GM of my guild.

My wife is.

She's pissed.

You don't live with her. I do.

Plz fix.
2 Likes
08/09/2018 11:32 AMPosted by Beteljuice
People keep saying that Bliz WANTED to nerf guilds and force their players into the new communities concept (which is still in its infancy and unsurprisingly clunky as it awaits the inevitable improvements). If we want any hope of continuing to enjoy this game, we must assume that Bliz is not simply acting as an evil empire looking to ignore as many players as they can. As a software developer who has lived through several of these disasters at various large companies, let me present an alternate timeline for how this all happened:


Okay I'll bite. Let's assume for the sake of argument that your alternate reality is the true reality.

08/09/2018 11:32 AMPosted by Beteljuice
1. Bliz game designers listened to users, and proposed the new Communities functionality to allow cross-server groups of like minded people.


If Blizzard game designers had listened carefully to the users, the new Communities feature would if anything been an entirely separate feature with an entirely separate set of functionality. It would not have borrowed any but the most common code and featuresets from the Guild Permissions and or Guild Controls featureset. In no rational world would the changes that have been made to the existing platform of guild controls have been sanctioned.

08/09/2018 11:32 AMPosted by Beteljuice
2. The scaled-back Communities interface was designed, and someone decided that there are synergies with the Guild functionality.


Synergy between featuresets and sharing common code base are far from equivalent concepts: Where Groupby and Having are all sql clauses. They all perform rowset functions in a row oriented database structure. But they are quite far from equivalent.

Where specifies a search condition and limits the rows returned to a meaningful set.
Groupby works on the rows returned by the where clause to summarize the rows into single/distinct groups and return one row for each group returned based on the aggregate function chosen in the select list.
Having acts as a filter on the Grouped rows returned by the GroupBy Clause.
If one wants to code without a having clause doing so is quite easy to do. However if one wishes to use Having one may do so without altering functionality of GroupBy or Where works.

08/09/2018 11:32 AMPosted by Beteljuice
3. Some gung ho coder saw that there were a number of flags for various permissions in the guild data. Since each flag requires data space and maintenance overhead, they proposed that all the flags could be replaced by an IsOfficer flag, simplifying the code measurably.


There are a couple different issues if this is the true state of affairs.
a) As in battle being noticed is not generally speaking a positive thing. There are bold soldiers and there are old soldiers but there generally aren't any old bold soldiers. The same can be said of coders. Coders who draw attention to themselves have risked their professional necks. Risking ones neck is not something that most companies will recruit for or encourage within their organization. Blizzard as a corporate environment is likely more strict about this than it is not strict about it.
b) Collaboration is useful for weeding out ideas that look good on paper but in practice have opposite or negative effects. In a collaborative environment this proposal might be brought up but it would certainly be shot down almost as quickly as the hole in the plan can be seen from miles away by the laity (we saw it
and rather quickly didn't we?)
c) Making a change to the database to correct the absence of data fields is actually quite simple if you already have some measure of Change Control in place and you have a well ordered plan for changing fields based on dimensional bi-temporal standard methodology. If you decide to revert a change in a bi-temporal model it becomes child's play to do so if your dimensional table is a type 3 SCD (Slowly Changing Dimension) this type of scd is also known as the alternate reality SCD and allows for both the IsOfficer flag field as well as the more granular fields (generally by hanging an outrigger dimension or lookup dimensional table off of the type 3 SCD). My assumption here is that the creator of the hypothesis is not fully conversant with data structures otherwise they would understand that additional fields are easily dealt with if you have thought of them far enough in advance. Blizzard had to do that sometime ago because this particular problem comes up ALL the time and is easily dealt with.


08/09/2018 11:32 AMPosted by Beteljuice
4. The proposal was OKed because the people who should have analysed the ramifications in much more depth were busy with the thousands of other changes in BfA, and didn't think of all the scenarios where the granularity was necessary.


This point in light of the rebuttals of point three above becomes moot as it should never become an issue given a properly implemented plan.

08/09/2018 11:32 AMPosted by Beteljuice
5. The code and database changes were made, and the data was converted into the new layout. Not enough noise was made soon enough in the alpha and beta to get it reverted before it was too late.


Given the ease at which database changes to dimensions are made as referenced above in my rebuttal to point three this should never have been an issue. The concepts of which I speak and their subsequent resolutions are some 35 years old at the time of this writing (circa 1983) and have been fairly and thoroughly addressed by both Bill Inmon and Ralph Kimball (the namesakes for the two most prominent methodologies used in Data Warehousing which is the subject matter you are attempting to reference) and both of those distinguished gentlemen have literally written all the books on the subject.

08/09/2018 11:32 AMPosted by Beteljuice
This brings us to the prepatch. GMs suddenly realize that they have been cut off at the knees. There is massive backlash (although I suspect that GMs make up maybe 1% of the player base, so what we consider massive is less so to Bliz). However, reverting the flags would require a database change to put back the fields that are now history.


Again see my rebuttal to point 3 above. Database changes on the back end that do not require new input from the client are done all the time. As there is no new input from the client the changes can be done seamlessly requiring little in the way of patching the client and likely not even requiring a server restart (although generally speaking that would be a good idea just to ensure stability)

08/09/2018 11:32 AMPosted by Beteljuice
A solid rule that smart companies follow during software upgrades is that you NEVER make a database change at the last minute, because it can cause way more damage than you can imagine if anything goes wrong.


There is a standard order that changes to software should be followed. Unlike client side data though, the database management systems if well maintained (as any production database absolutely must be if you want accurate data) is probably the ONE place that you can be sure that data restorations can occur as they routinely occur and they routinely occur frequently. In fact that pretty much is the reason that transactional database management systems exist. If there is one system in your organization that is likely to have a backup its the dbms. Now if you had said that you NEVER make a database change at the last minute BECAUSE you are doing a software upgrade that would be closer to the truth. When you make changes to data storage and retrieval systems you do them one at a time and you do not concurrently change data structures while also changing operating system functionality, and before any change is made you create a backup of that point in time and then make two copies of that backup one to leave online in case something does go kerblooey and one to take offline for BC/DR.

08/09/2018 11:32 AMPosted by Beteljuice
Thus, I think Bliz is truly listening to us but can't do anything until the first post-patch. Fixing things like this in a hotfix has probably been the root cause of major fiascos in the past, so no amount of yelling or pleading will make them risk the other 99% of their user base, and they will fix this when the expansion is out and relatively stable.


In light of the refutations outlined above I believe your summation to be inaccurate at best.
08/09/2018 02:21 PMPosted by Mgann
/thread


Feel free to find other threads to read or even go play the game. But unless you have something constructive to post, it would be better for all concerned if you refrained from violating the Code of Conduct with your posts:

I quote the offended section of the Code of Conduct here:

Spamming or Trolling
This category includes:

...
Numbering a thread, IBTL, TLDR, or any other fad statements
...
08/09/2018 04:26 PMPosted by Venjin
Gonna be honest Blizz. I'm not the GM of my guild.

My wife is.

She's pissed.

You don't live with her. I do.

Plz fix.


Brevity thy name is Venjin!
08/06/2018 12:18 PMPosted by Dufas
just remember options are those things you think you want but really dont


Huh. Not sure i agree with this. As long as options are truly that...options so you can toggle on and off...take advantage of or not...then more options are always good.
08/09/2018 05:28 PMPosted by Æthelwulf
In light of the refutations outlined above I believe your summation to be inaccurate at best.


Sorry to say, although your refutations sound impressive in theory, they don't stand the test of reality. Talking about the abilities of modern databases is moot when discussing a database that has probably been carried forward from over 10 years ago. And your backup plan is great - in a mostly static environment where you have a transaction log since the last backup. I'm sure Bliz would be most amused that you are suggesting that they "simply" bring back the backup from pre-prepatch. It shouldn't be an issue convincing people that their progress of the past few weeks was "only a dream".
08/09/2018 06:02 PMPosted by Beteljuice
08/09/2018 05:28 PMPosted by Æthelwulf
In light of the refutations outlined above I believe your summation to be inaccurate at best.


Sorry to say, although your refutations sound impressive in theory, they don't stand the test of reality. Talking about the abilities of modern databases is moot when discussing a database that has probably been carried forward from over 10 years ago. And your backup plan is great - in a mostly static environment where you have a transaction log since the last backup. I'm sure Bliz would be most amused that you are suggesting that they "simply" bring back the backup from pre-prepatch. It shouldn't be an issue convincing people that their progress of the past few weeks was "only a dream".


Okay, lets clear the air on a few things.

1) In most production environments the industry gold standard is to maintain a 180 day retention period for data.

2) In most production environments a FULL backup of the database is done Nightly along with a Transaction Log Backup.

3) a Differential backup is done according to the schedule outlined in the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) and the very first thing done when ANY maintenance is done, after placing the database in single user mode, and whenever an unplanned restart, abend, abort, or system failure occurs is to take a tail log backup before restoring the database to capture any transactions that occured since the last incremental or full backup. So, for example if your RTO says you can be offline for 8 hours before all heck breaks loose and your RPO says 15 minutes worth of data loss is acceptable then you do Differential Backups every 8 hours and Incremental database backups every 15 minutes with a t-log backup every 15 minutes. In this way when you do need to perform the tail log backup before restore and if that tail log backup corrupts then you are not outside of your acceptable loss of data value.

4) Modern Transactional Database Technology has been around quite some time. Microsoft SQL Server (likely the weakest of the OLTP RDBMS's out there) has had true differential and incremental backups as part of its architecture since 2000. Tail Log transaction log backup before restore was added in 2005 and improved in 2008 and 2010 versions. Oracle has had those features since the early 1990's. Sybase invented the tail log process in 1985.

5) We are not discussing a single database nor even a single instance of a relational database management system. We are discussing the data storage and retrieval engine of a multi billion dollar enterprise. They are going to have enterprise class hardware, software, data security policies, data retention policies, and relational and dimensional data management systems. It isn't a singular database carried forward over a period of nearly 14 years. That would be the equivalent of Google operating off of one small data center. We are talking about millions of rows of Fact Table Data that needs to be accessible and readable in microseconds. Hundreds to hundreds of thousands of rows of dimensional and quasi dimensional data. The gameplay transactional system alone is going to have some of the most sophisticated indexing you have ever seen and then the reporting databases are going to take all of that CRUD data as inputs and flatten it out so that it can be sliced and diced to show trends along several axis at once.

It isn't something cobbled together over the years in someones dusty garage. Its truly BIG data.

6) Transaction logs are not kept between database backups. They exist as a record of data from moment to moment. They often times are larger than the actual databases in OLTP systems. OLAP is less t-log intensive but still uses them and they are kept in a moment to moment state for the life of the database.
1,100 posts in this thread and "nothing to share"
While explaining how infrastructures work in a software company is very educational and I do appreciate the information this still doesn't excuse what Blizzard has done here.

Basically they needed to assess their changes to their product more before they put it into live or even beta but for some reason this seemed so important and rushed that well they skipped a step.

As for it being difficult for them to revert the changes, everything you guys have been saying is basically they changed their main code / database and can not revert easily.

Isn't it also possible that the changes they made were modular in nature that the routines and databases they modified are smaller and not something that is part of lets say the coding for characters and stats but a smaller routine/module plus database that is connected to the bigger code.

I bet its more likely their programming has changed a great deal since its beginning and many sections that are part of the game are actually built with the idea of portability so when the infrastructure needs to be rebuilt you can port sections of the application to the new infrastructure and test it to insure it all works while still working on it.

If this is the case the code is probably still in the game, just remarked out, and the old data that the code touched is probably still stored in place but nothing is accessing it. I suggest the fact that the old Guild Roster command works and brings up the old UI as proof of that.

So if this is the case and what I see is accurate then reverting the code is possible with minimal work.
08/09/2018 04:26 PMPosted by Venjin
Gonna be honest Blizz. I'm not the GM of my guild.

My wife is.

She's pissed.

You don't live with her. I do.

Plz fix.


You poor soul! Let's join together to save this person and their spouse!
Ok first off...

08/06/2018 10:15 AMPosted by Ythisens
Extended the cap once more on this one!

As you can imagine we're aware of this thread but don't have anything to share at this time but just wanted to say thanks for the continued feedback on this one. As soon as we have something to share we will post that for you guys.


Thank you for the second extension, and the recognition of this post. Even though you have a non-answer it's still an answer.

08/08/2018 07:17 AMPosted by Greenstone
Please add this to the HELP / SUBMIT BUG, if you are a guild master, and let them know you have similar feelings. Remember submit bug text is limited, so if you change anything make sure to clearly state the BUG which is related to the "Is Officer" permission not being granular enough.


This is more than likely a canned response. To be fair this thread should be attention enough, but couldn't hurt to put in a report.

08/08/2018 07:23 PMPosted by Katri
No one can invite in our guild besides officers, they probably would let me be one but really unnecessary just let me invite again


I just want to be clear on this one. You can still set who can and can not invite, demote or promote individually. So, if you are not able to invite people then it was set by the Guild Leader. Also there IS a bug on this part. You have to type /groster to pull up the original GUI for a functioning Invite button.

Things I personally would like to see for guilds and how it would affect them are as follows:

1. The "Is Officer" button needs to be unbundled. This would allow for some of the more granular controls back, and give guild leads a bit more customization to their ranks. While I don't like it, I can see where it would come in handy. Again I suggest an "Advanced" option for this with the original options reinstated.

2. Public Note needs to be reworked. I really think everyone should be able to adjust have access to their own Public Note, with the option for the Guild Lead to remove that access to a rank or give permissions for others to be able to change someone else's Public Note. Example:

08/09/2018 11:44 AMPosted by Lueran
My guilds pretty annoyed that people can’t edit their own PUBLIC notes now without being an officer. We put notes on people to tell them apart, especially if they’re alts of a longtime member or a newbie. Now it’s just tedious that one of our few people who has been entrusted with the power to demote and KICK people from the guild has to be online to put a note on someone to say, “Oh hey, this is one of Lue’s alts btw” We gave everyone the ability to do that, particularly our recruitment officers (the rank below those with the discipline roles), because it’s incredibly tedious to make them do anything.


I've had this same issue with my guild as well, I had to download the Guild Roster Manager addon to circumvent this. However, this is a band aide to the issue.

3. The Chat Log, needs to have an option to be purged, or at least have the option to turn on or off the record function. There are to many possible awkward situations as I have explained earlier in this thread, (on Page 50).

4. Chat Permissions need to still be available to control. Example:

08/08/2018 01:30 PMPosted by Dynara
Had a person in my guild acting like a jerk for hours until an officer could boot him. Boy that Time Out rank I have set up that would restrict a person like that's ability to speak in chat would have really come in handy.....Oh that's right, you can't block people's ability to chat in guild chat under this new system. I lost many people because they /gquit because of this dope. They thought we condoned this type of behavior.


07/31/2018 05:56 PMPosted by Barroo
Why oh please why, would you change the guild controls?? Why would you take away the controls that help to maintain peace and harmony?? Our guild has run peacefully for TWELVE years, and one of the ways we had of calming people down, of "disciplining", or sometimes just for fun, was to demote them to a rank that couldn't speak in guild chat. WHY would you remove this?? When someone gets hacked, we could demote them so that we didn't have to boot them, but no one would be forced to deal with the hacker.


07/17/2018 11:56 AMPosted by Kaiyeri
Not to mention the numerous RP guilds who used officer chat as their RP chat in order to leave guild chat as their out of character chat.


5. Something that I would like to see in Guilds or even Communities, is the option to link characters together if they are from the same account. This would make managing Alts a lot easier on the roster instead of just having players put a Public Note in. This would be quite useful as well for Guild Leads who may swap Mains and not change over the Guild Leadership to that character. Thus risk loosing the guild cause they haven't logged on to one specific character.

6. Something that was said earlier in this thread that upset me was the potential loss of the Last Online. This needs to remain for active rosters. I've stated this much before in my earlier posts. However, this needs to be cleaned up in the new GUI. There is no way to currently sort players by this and their rank. Please fix this as well.

7. Something that was removed from guilds a while back and understandably so because it was being abused was Cash Flow. I would like to see this reimplemented but in a different way. I personally don't offer guild repairs. This is because it can drain your coffers faster than you can blink, particularly if you have a larger guild. Instead we use the money to buy materials for flasks, food and whatnot to support our raiders in a more effective way. What I propose is to have a separate gold counter for the guild, that it's sole purpose is for guild repairs, and it can't be withdrawn from by the Guild Lead. This way you don't have people starting guilds and mass inviting players for the purpose of gold hording/farming.

On this topic as well, the Guild Challenges, the money reward needs to be increased to stay in pace with the inflation of the economy of the game. 3.4k per week with the current rewards is honestly a joke.

8. Something that Guild Leads and Players in general have been crying for years now. Better Guild Finding and Recruitment in the game. I'm sorry but lurking the forums, spamming trade chat, and going into the social tab looking for unguilded players is not my idea of fun. Not to mention the "Recruitment" in the game does not alert you if someone has put there name in. Nor does it show if that player is on or offline. It's a huge waist of code in my opinion.

9. Guild Message of the Day… More like never seen message of the day. This gets lost in addon spam. You almost never see it. I use it but I have to go back into Discord to do announcements so people know what's going on. It would be nice if this was a little more prevalent.

All of these things would be a QoL as a Guild Lead.

I have one other thing that I would like to mention but is not related to guild controls completely. This is the Master Looter/Personal Loot systems.

Guilds generally use Master Loot, not because of wanting to horde loot for certain special people, (not saying this don't happen, and it's a shame when it does), but to appropriate gear out a bit more evenly. With the changes made to threat in the game, there is a real potential for one person to get a lucky steak and get completely geared. This is not a bad thing in essence, but if that DPS player all of a sudden out gears the tanks by a large amount, there are going to be some serious threat issues.

I played back in TBC as a tank, and tanks and heals were geared first just because of the threat game. I can see some serious problems with this if things are not dispersed evenly, if we are bringing some of these older systems back. What bothers me is that IF you are in a guild environment then you know what loot system is being used, and you go into a raid team understanding this. As a player if you didn't agree with it, then you wouldn't be raiding what said team/guild. If you pugged 4-5 people anyway it would revert to Personal Loot anyway. I really don't know why we moved to Personal Loot, but I'm not a fan of this.

We went to Personal Loot in LFR that could be traded freely….
To many people complained about other players harassing them about not trading gear….
Gear now that is received, if it's a higher ilvl or part of a set that you don't already have it auto binds……
Personal loot forced even on premade groups…..
Not able to trade gear to players that could use said item when the original recipient DOESN’T need/want it.

This is not good… not good at all.
Hello blues, keeping this thread at the top. Revert your dumb changes that no one asked for.
How is this not fixed yet?